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.
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.