It assumed at this point that you have successfully installed OpenLink's client and server components on one or more computers within your I.T. infrastructure.
Understanding the fundamental concepts that drive the OpenLink Data Access Drivers for Progress is central to you exploiting the deliberate simplicity of our product architecture. A failure to grasp these concepts will certainly make the last sentence an absolute contradiction in terms.
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.
|
The steps explained:
OpenLink Database Agent For Progress instance uses your chosen Inter Process Communications (IPC) mechanism to initialize a session with a Progress Database Server that supports the chosen IPC mechanism. The default mechanism chosen by the OpenLink Database Agent For Progress is shared memory. You can opt to use TCP sockets by doing one of the following (as long as you have started a TCP sockets based Database Server for your Progress Database Engine by using the command:
proserve <dbname> -S <service name> -N TCP H localhost):
Place the Progress Database Connection Parameters - S <service name> -N TCP H localhost into the "Options" field of the OpenLink ODBC Data Source Configuration Utility, should you be using OpenLink ODBC Drivers.
Place the Progress Database Connection Parameters - S <service name> -N TCP H localhost as "/OPTIONS" JDBC URL attribute values, should you be using OpenLink Drivers for JDBC.Place the Progress Database Connection Parameters - S <service name> -N TCP H localhost as "OPTIONS" connect string values, should you be using OpenLink UDBC or OpenLinks Unix based ODBC Drivers.
The OpenLink Session Rules Book (oplrqb.ini) allows you to control this behavior centrally, alleviating yourself from the 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.
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 create an entry in the "services" file (situated in the UNIX "/etc" directory) for one or more Progress TCP Sockets based Database Servers. The "services" file is standard TCP configuration file that is used to match Service Names to the TCP port number from which their services can be accessed. The entries in this file follow the format shown below:
| Service Name | Port/Protocol | Comment |
|---|---|---|
| netwall | 533/udp | # -for emergency broadcasts |
| uucp | 540/tcp | # uucp daemon |
| remotefs | 556/tcp | # Brunhoff remote filesystem |
| pppmsg | 911/tcp | # PPP daemon |
| listen | 1025/tcp | # listener RFS remote_file_sharing |
| nterm | 1026/tcp | # remote_login network_terminal |
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 Servers 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
(Assuming a Progress Database named "sales.db" using as TCP Service "pro8srv")
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
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 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
As explained earlier an OpenLink Database Agent for Progress is a combination of OpenLink specific libraries (data access and network server modules) and Progress specific libraries provided situated in the "probuild" sub-directory under your Progress installations $DLC directory.
Should you desire the superior performance that Shared Memory has over TCP sockets, then rebuilding/relinking your OpenLink Database Agent for Progress provides an alternative solution to Shared Memory incompatibility problems that may be impeding your ability to establish an OpenLink session with your Progress Database Server.
Activity Prerequisites
Rebuild/Relink Steps
Create a UNIX environment variable named "PROLOAD" and set its value to $DLC/probuild From the UNIX command line prompt this is achieved by typing in the following:
PROLOAD=$DLC/probuild ; export PROLOAD
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.
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:
The number of seconds a login attempt can continue before timing out. The default is 20 (values are of type REG_DWORD).
The number of seconds a query can run (total processing time) before timing out. The default is 60 (values are of type REG_DWORD).
The number of seconds a cached connection can remain idle before timing out. The default is 600 (values are of type REG_DWORD).
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).
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).
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).
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).
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.
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).
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).
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).
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.
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.
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).
|
Previous
Linking OpenLink DB Agents |
Chapter Contents |
Next
Application Server Architecture |