This is an old revision of the document!


Development: ODBC Interface

Overview

The Omnidex ODBC Driver is a standard-compliant ODBC driver that provides ODBC access to Omnidex Environments. ODBC is most commonly found in a Microsoft Windows environment; however, it can also be found on UNIX platforms through available ODBC managers such as unixODBC. Omnidex's ODBC Driver is available on both a Microsoft Windows and a Linux environment.

The Omnidex ODBC Driver is used for client/server access to an Omnidex Environment. Applications can access Omnidex Environments using the standard API calls. Organizations can also use the multitude of third party tools and applications, such as Business Objects, Impromptu, MicroStrategy and Informatica. ODBC also provides access to common office tools, such as Microsoft Access, Excel and Word.

The Omnidex ODBC driver is based on the Version 2.0 of the ODBC standard.

Integrating Omnidex with Third-Party Applications

The Omnidex ODBC Driver allows easy integration with many third-party applications. It is often as simple as providing the third-party application with an appropriate connection string to point to the existing Omnidex Environment.

Access Omnidex through the ODBC API

Applications may choose to call the ODBC API directly in order to access the Omnidex Environment. Refer to the sample ODBC program to see an example of a basic application.

An ODBC application must begin by obtaining a handle for the environment and then a handle for the database connection. Memory is allocated for these handles and the information they store. A statement handle, used for processing SQL statements, will be obtained later in the application. Every subsequent CLI call will be passed one of these three handles.

The environment handle must be the first handle established. It refers to the data object that contains global information about the current state of the application. The program allocates this handle by calling the SQLAllocEnv() CLI function call. Only one environment handle can be allocated per application, and it must be allocated before connection handles can be allocated.

The connection handle must be established after the environment handle, but prior to any other CLI function calls. It refers to a data object that contains information associated with a database connection. This data object includes general status information and diagnostic information. The program allocates each connection handle by calling the SQLAllocConnect() CLI function call, and must allocate a connection handle for each connection it makes to a database server. These connection handles are then used to establish database connections and allocate SQL statement handles for use within those connections.

The statement handles refers to a data object that contains information about an SQL statement. This data object includes information such as the SQL statement text, any dynamic SQL statement arguments, cursor information, bindings for dynamic SQL statement arguments and columns, result values, and status information. A program allocates a statement handle by calling the SQLAllocStmt() CLI function call; a statement handle must be allocated for an SQL statement before that SQL statement can be executed. Also, each allocated statement handle must be associated with a specific database connection handle. The maximum number of statement handles that can be allocated at any one time is limited only by the amount of available system resources (usually stack space).

Cursors

It is not necessary for an ODBC CLI application to implicitly open cursors. Each time the SQLAllocStmt method is called, the Omnidex ODBC driver calls oaopencursor. Each HSTMT object created with SQLAllocStmt, has its own cursor and should therefore, be considered a cursor itself.

Switching between cursors is simply a matter of referring to the different HSTMT objects in the ODBC application.

As noted above, it is not necessary for an ODBC CLI application to implicitly open cursors. However, it is possible to do so by using an OPEN CURSOR statement. The OPEN CURSOR statement is passed through an HSTMT object in the same manner as any SQL statement that does not return a result data set.

To use a cursor that was opened implicitly through an OPEN CURSOR statement, a SQL statement must append an ON CURSOR n clause to the end of the statement.

Use a CLOSE CURSOR statement to close cursors that were implicitly opened with the OPEN CURSOR statement.

Additional Resources

See also:

 
Back to top
dev/odbc/home.1294789235.txt.gz ยท Last modified: 2016/06/28 22:38 (external edit)