Accessing Data with ODBCDirect

   

When your application uses ODBCDirect, it is actually using RDO. You might reasonably ask: "Why not just use RDO?" The answer is that complete conversion to RDO would require many more changes than the few simple adjustments needed to use ODBCDirect.

It's worth noting that ODBCDirect isn't exactly direct. To access a data source requires negotiation with DAO objects, conversion through an ODBCDirect translation layer, an RDO ODBC call, and presentation to the ODBC driver, which finally translates your data access request into database engine code.

Note   Unlike standard DAO, you can't use ODBCDirect to perform DDL (Data Definition Language) operations that affect the structure of your database, but you could achieve the same effect using SQL statements. Also, ODBCDirect cannot perform heterogeneous joins across tables from multiple data sources — one of the strengths of DAO.

An ODBCDirect-based application uses the following operations to access a data source.

• Create the workspace   Defines the user session, including user identification, password, and database type.
• Open the connection   Specifies a connection string for a particular workspace with information such as data source name and database table.
• Open the recordset   Runs an SQL query (with or without parameters) and populates the recordset.
• Use the recordset   The query results are now available to your application. Depending on the cursor type, you can browse and change the row data.
• Close the recordset   Drops the query results and closes the recordset.
• Close the database   Closes the database and releases the connection.

Even though ODBCDirect uses RDO, there are some important features that are handled differently. For example, with ODBCDirect you must create a new Workspace object for each different cursor on a specific connection. Transactions are coordinated at the workspace level, not at the connection or database level. Finally, even though ODBCDirect supports asynchronous operations, you must poll for completion (there is no callback).

Compared to DAO, one of the best enhancements in ODBCDirect is batch optimistic updating. With batch optimistic dating your application can cache data locally and refresh the server in batch mode. This tends to be very fast because it significantly reduces back-and-forth traffic on the network. The reference to "optimistic" has to do with the underlying assumption that the locally changed records have not been concurrently updated by another process.

ODBCDirect is a good data access technology that is limited to ODBC data stores. If your application requires access to other types of data stores, ODBCDirect cannot provide it.