Remote Data Objects (RDO) was Microsoft’s solution to the slow Performance created by DAO. For talking to databases other than Microsoft Access, RDO did not use the Jet Engine like DAO; instead, it communicated directly with the ODBC layer. Figure below shows this relationship.

Removing the JET Engine from the call stack greatly improved performance to ODBC data sources. The JET engine was only used when accessing a Microsoft Access Database. In addition, RDO had the capability to use client-side cursors to navigate the records, as opposed to the server-side cursor requirements of DAO.This greatly reduced the load on the database server, enabling not only the application to perform better,but also the databases on which that application was dependant.

RDO was primarily targeted toward larger, commercial customers, many of whom avoided DAO due to the performance issues. Instead of RDO replacing DAO, they largely co-existed. This resulted for several reasons:

1. First, users who developed smaller applications, where performance wasn’t as critical, didn’t want to take the time to switch over to the new API.
2. Second, RDO was originally only released with the Enterprise Edition of Visual Basic, so some developers didn’t have a choice.
3. Third, with the release of ODBCDirect, a DAO add-on that routed the ODBC requests through RDO instead of the JET engine, the performance gap between the two became much smaller.
4. Finally, it wasn’t long after the release of RDO that Microsoft’s next universal access API was released.