Beginning with Visual Basic 4, Microsoft introduced Remote Data Objects (RDO) as an alternative to Data Access Objects (DAO). These new RDOs are included only with the Enterprise Edition of Visual Basic. What RDOs allow you to do is bypass the Microsoft Jet database engine and go directly to the ODBC datasource for SQL-based databases. In a sense, it’s a lot like using pass-through mode on an entire database with DAOs, where the Jet engine is only providing a means of accessing the database but is not performing any database management.
RDOs are very similar to using DAOs in ODBCdirect mode, which was introduced with Visual Basic 5. The difference is that ODBCdirect mode uses RDOs to perform all of the database access. As a result, you have an additional layer of the DAOs on top of the RDOs, each adding its own layer of processing into the mix. However, there is nothing between RDOs and the ODBC interface to add overhead to your database access. The only way you can get any closer to the ODBC interface is to make ODBC API calls from Visual Basic, only you lose use of all built-in data controls available with the Visual Basic data access options.
You can gain many of the benefits of RDOs by using regular DAOs in ODBCdirect mode and still have the DAO object model to work with. However, the ODBCdirect mode is an in-between solution, you don’t have full DAO functionality, and you don’t have full RDO functionality. But if you’re more comfortable with DAOs, or you need to go between multiple databases, some of which have to use the Jet engine, then you are probably better off using DAOs in ODBCdirect mode. On the other hand, if you are only going to be using SQL-based databases that have ODBC interfaces, you are better off in the long run to use RDOs.