Your OpenLink Data Access Driver Suite (Multi-Tier Edition) consists of the following components, subdivided by prime function:

The prime function of your OpenLink Components does not determine their physical location within your I.T. infrastructure, this is driven instead by the logical structure and nature of your database connectivity requirements.

A process diagram is provided below to assist with the understanding of how the various OpenLink components work in concert, with the sole objective of providing you with Secure, High-Performance, and Highly Configurable access to Progress Database Engines.

Figure8.43.Progress Connection Conceptual Diagram

The steps explained:

The OpenLink Database Agent for Progress is a Hybrid of OpenLink & Progress ESQL/C components, indicating that the actual OpenLink Database Agent for Progress is for all intents and purposes a Progress ESQL/C client.

The files "proxxx_sv" or "proxx_sv.exe" are your OpenLink Database Agent for Progress executables (note: xxx represents Progress major and minor release numbers e.g. Progress 7.3C would be represented as pro73c_sv). These files are always situated in the "bin" sub-directory of your OpenLink installation directory.

When you attempt to make an ODBC/JDBC/UDBC connection to your Progress Database Engine(s), and you encounter a problem, one of the following error conditions would typically be presented to you via your ODBC/JDBC/UDBC application:

The conditions above arise due to the fact that the OpenLink Database Agent for Progress not being built using Progress ESQL/C libraries that do not match your Progress Database Server to the exact minor release. This is to say that although the OpenLink Database Agent for Progress may have been built using ESQL/C libraries for Progress 7.3A, you will still have a version incompatibility problem of this nature should you attempt to connect this ESQL/C client to a Progress 7.3C Database Server process.

This error condition arises as a result of the fact that the OpenLink Database Agent for Progress defaults to using Shared Memory for its Inter Process Communications (IPC) , and that Shared Memory is very version sensitive nature albeit the fastest IPC mechanism .

There are two possible ways to work around this situation when it arises.

Pre-Configuration Check List:

You need to choose the name of a service and a port number that is not currently used by a tcp service (in the case illustrated above, for example, number 1026 is already being used).

Thus, if you chose to use the name "pro8srv" for your Progress TCP Sockets based Database Server’s Service Name. And you chose to make its services available at TCP port # 9001 (and you have checked the file to make sure it is not being used) you would add the following entry (note that the third entry is simply a comment as it is preceded with a "#"):

pro8srv 9001/tcp # for Progress database sales 

¶

Configuration Steps

	Note:
	(Assuming a Progress Database named "sales.db" using as TCP Service "pro8srv")

• Progress Server Components

  • Assuming the database file "sales.db" is situated in directory "/usr/data". Start your Progress TCP Sockets based Database Server process using the command:

    >proserve /usr/data/sales.db -S pro8srv –N TCP –H localhost 

• OpenLink Server Components (Database Agent for Progress)

  • The OpenLink Session Rules Book (oplrqb.ini) allows you to control all OpenLink Data Access clients (ODBC/JDBC/UDBC) centrally, alleviating yourself from the time cost of maintaining numerous client based connection parameters.

    This is done by placing the Progress Database Connection Parameters -S <service name> -N TCP –H localhost as "ConnectOptions" section-key values within the Progress Database Agent configuration ( "[generic_prox]" ) section of the Session Rules Book e.g.:

    [generic_pro8]
    Program = pro8_sv
    ServerOptions = -q –d mdy –TB 30 –TM 30 –e 25
    Database = /usr/data/sales.db
    ConnectOptions = -S pro8srv –N TCP –H localhost
    

• OpenLink Client Components (Drivers for ODBC/JDBC™/UDBC)

  You only have to resort to the steps below if circumstances within your organization demand client side configuration, otherwise the server based approach using the OpenLink Session Rules Book (oprqb.ini) is much more effective and convenient.

  • OpenLink ODBC Drivers - Place the Progress Database Connection Parameters: -S pro8srv –N TCP –H localhost into the "Options" field of the OpenLink ODBC Data Source Configuration Utility

  • OpenLink Drivers for JDBC ™ - Use the Progress Database Connection Parameters: -S pro8srv –N TCP –H localhost as "/OPTIONS" OpenLink JDBC URL attribute values e.g.:

    jdbc:openlink://dbservermachine/DSN=dsn_progress/OPTIONS=-S pro8srv –N TCP –H localhost
    

  • OpenLink UNIX based ODBC or UDBC Drivers - Use the Progress Database Connection Parameters: -S pro8srv –N TCP –H localhost as "OPTIONS" connect string values e.g.:

    DSN=dsn_progress;OPTIONS=-S pro8srv –N TCP –H localhost
    

Our ODBC Drivers facillate the support of the above through the use of a custom "Data Dictionary File", this file is built by running the OpenLink provided Progress Program File "setup.p" situated in the "bin" sub-directory below the OpenLink base installation directory.

Once the script has been run, modify the OpenLink "Session Rules Book" using the gudilines displayed when the " setup.p" program completes.

Note: To make use of Progress Database Triggers please ensure that the Logical Database name to which your Triggers have been compiled matches the value that you provide to the "-ld" parameter when setting your Progress Database Connect options during the execution of "setup.p" .

Example:

If you have compiled your triggers against a database physically identified as "/usr/progress/demo.db" but logically identified as "mydemo" your "setup.p" Database Connection String would be:

/usr/progress/demo -ld mydemo

The Mysterious "Admin" Account & Disabling the JET Scrollable Cursor (Dynaset) Facility

Please ensure that you have the following OpenLink Settings enabled :

Client

Server

[Mapping Rules]
;*:*:blank:*:*:*:rw = reject You should specify a username and password
*:*:Admin:*:*:*:rw = reject User Admin Account Does Not Exist In Your Progress Database

The above alleviates the need to depend of JetTryAuth or TryJetAuth.

The following sections describe Windows registry settings settings for the Microsoft Jet database engine for connection to an ODBC database. These registry settings must be added by the user or by your application; the ODBC Driver Setup program does not write default values to the location:

\HKEY_LOCAL_MACHINE\Software\Microsoft\Access\7.0\Jet\3.5\Engines\ODBC

Initialization Settings for Jet-connected ODBC Databases, found at:

\HKEY_LOCAL_MACHINE\Software\Microsoft\Office\8.0\Access\Jet\3.5\Engines\ODBC

folder contains initialization settings for the Microsoft Jet database engine. Before you can add any of the following values to the registry, you must create the ODBC folder under the Jet\3.5\Engines folder.

To create the new folder, open the Jet\3.5\Engines folder in the Registry Editor and click Add Key on the Edit menu. In the Key Name: edit box, type ODBC and click OK. The Registry Editor creates a new folder below the Jet\3.5\Engines folder.

	Note:
	If you are using Windows NT, the Add Key dialog box also contains an edit box for the registry key class; you can leave this setting blank.

Typical settings for the entries in the Jet\3.5\Engines\ODBC folder are shown in the following example.

LoginTimeout=20
QueryTimeout=60
ConnectionTimeout=600
AsyncRetryInterval=500
AttachCaseSensitive=0
AttachableObjects='TABLE','VIEW','SYSTEM TABLE','ALIAS','SYNONYM'
SnapshotOnly=0
TraceSQLMode=0
TraceODBCAPI=0
DisableAsync=0
JetTryAuth=1
PreparedInsert=0
PreparedUpdate=0
FastRequery=0

The Jet database engine uses the ODBC entries as follows:

LoginTimeout. The number of seconds a login attempt can continue before timing out. The default is 20 (values are of type REG_DWORD).

QueryTimeout. The number of seconds a query can run (total processing time) before timing out. The default is 60 (values are of type REG_DWORD).

ConnectionTimeout. The number of seconds a cached connection can remain idle before timing out. The default is 600 (values are of type REG_DWORD).

AsyncRetryInterval. The number of milliseconds between polls to determine if the server is done processing a query. This entry is used for asynchronous processing only. The default is 500 (values are of type REG_DWORD).

AttachCaseSensitive. An indicator of whether to match table names exactly when linking. Values are 0 (link the first table matching the specified name, regardless of case) and 1 (link a table only if the name matches exactly). The default is 0 (values are of type REG_DWORD).

AttachableObjects. A list of server object types to which linking will be allowed. The default is: 'TABLE', 'VIEW', 'SYSTEM TABLE', 'ALIAS', 'SYNONYM' (values are of type REG_SZ).

SnapshotOnly. An indicator of whether Recordset objects are forced to be of snapshot type. Values are 0 (allow dynasets) and 1 (force snapshots only). The default is 0 (values are of type REG_DWORD).

TraceSQLMode. An indicator of whether the Jet database engine will trace SQL statements sent to an ODBC data source in SQLOUT.txt. Values are 0 (no) and 1 (yes). The default is 0 (values are of type REG_DWORD). This entry is interchangeable with SQLTraceMode.

TraceODBCAPI . An indicator of whether to trace ODBC API calls in ODBCAPI.txt. Values are 0 (no) and 1 (yes). The default is 0 (values are of type REG_DWORD).

DisableAsync. An indicator of whether to force synchronous query execution. Values are 0 (use asynchronous query execution if possible) and 1 (force synchronous query execution). The default is 1 (values are of type REG_DWORD).

JetTryAuth. An indicator of whether to try using the Microsoft Access user name and password to log in to the server before prompting. Values are 0 (no) and 1 (yes). The default is 1 (values are of type REG_DWORD).

PreparedInsert. An indicator of whether to use a prepared INSERT statement that inserts data in all columns. Values are 0 (use a custom INSERT statement that inserts only non-Null values) and 1 (use a prepared INSERT statement). The default is 0 (values are of type REG_DWORD).Using prepared INSERT statements can cause Nulls to overwrite server defaults and can cause triggers to execute on columns that weren't inserted explicitly.

PreparedUpdate. An indicator of whether to use a prepared UPDATE statement that updates data in all columns. Values are 0 (use a custom UPDATE statement that sets only columns that have changed) and 1 (use a prepared UPDATE statement). The default is 0 (values are of type REG_DWORD).Using prepared UPDATE statements can cause triggers to execute on unchanged columns.

FastRequery. An indicator of whether to use a prepared SELECT statement for parameterized queries. Values are 0 (no) and 1 (yes). The default is 0 (values are of type REG_DWORD).