Reliable Transaction Router
Installation Guide
Previous Contents

B.5.5 Using the Cursor Library

The OOR ODBC driver connect option SQL_ODBC_CURSORS is set to SQL_CUR_USE_ODBC. Attempting to change this with a call to sqlsetconnectoption is not supported and will return the message "Driver not capable". This ensures that the Driver Manager loads and uses the ODBC Cursor Library for functions requiring use of the cursor such as sqlextendedfetch .

B.5.6 Setting Session Characteristics

The implementation model used by OOR is that there is an OORO7 server process continuously running on the host with access to the ORACLE database. (This process is an RTR server application.) The OORO7 server process establishes a connection to the database using a valid username and password when it is started, and maintains the same connection for the life of the process.

When an OOR client (ODBC application under Windows) starts, it initiates an ODBC session by calling sqlconnect() ; this opens an RTR client channel. All ODBC calls made by the application are subsequently converted to SQL and sent through RTR to the OORO7 server running on the host. They are then executed by the database running on the host. The the client application is accesses the database on the host (with the username under which the RTR server is running on the host).

This model allows many OOR client applications to access one RTR server on the host, and all clients access the database as the user under which the RTR server is running. Thus, care should be taken if setting session-specific characteristics. These are set for the session that the RTR server has made to the database, and they are valid for every client that makes a connection to this server.

For example, using SQL*Plus: 


    SQL> ALTER SESSION SET SQL_TRACE=TRUE;

This command enables tracing; since the command is executed on the session established by the RTR server on the database, it means tracing will remain in effect for every client that connects to the RTR server until a client specifically disables it.

Typically, an OOR configuration is set up so that a normal unprivileged user would not be able to modify session characteristics. A server running on behalf of the database administrator (DBA) can be set up to handle database specific requests (for example, ALTER SYSTEM) that would not normally be available to the unprivileged user.

B.5.7 Using PL/SQL Procedures

When writing PL/SQL procedures for execution on the OOR server do not use the characters ":" or "?" within the comments. This is because the OOR driver would interpret these as placeholders for variables and the command to fail. For example: 


    create table gc__charting ( 
      owner        varchar(30),    /* owner ID */ 
      x1_axis_type integer,        /* axis data type:, date, or discr */ 
      x1_scale_fnc integer         /* scale function?, log, pct */ 
    )

This will be interpreted by the OOR driver as: 


    create table gc__charting ( 
      owner        varchar(30),    /* owner ID */ 
      x1_axis_type integer,        /* axis data type:C1 , date, or discr */ 
      x1_scale_fnc integer         /* scale function:C2 , log, pct */ 
    )

The OOR server will parse this statement, and then attempt to do a describe of columns C1 and C2, which will fail.

B.5.8 Changes and Corrections

B.5.9 OOR Restrictions

User authorization is not supported. The impact of this is that anything typed in to the username and password fields is ignored for connection. However, the fields are used as an (implicit) qualifier when selecting tables by name, for example.

Previous Contents Contents