DAO RDO ADO ado.net

Ado
ADO isn ' t automatically code-compatible with your existing data access applications. While ADO encapsulates the functionality of DAO and RDO, you are must convert many of the language elements over to ADO syntax . In the some cases, this would mean only a simple conversion of some functions of your of the code. In other cases, it might is best to rewrite the application using ADO ' s new features.

DAO (Data Access Objects) was the the "object-oriented interface that exposed" Microsoft Jet Database engine (used by Microsoft Access) and allowed Visual Basic developers to directly connect to Access Tables-as the as other databases- Through ODBC. DAO is suited the best for either Single-system applications or for small, local deployments.

RDO (Remote Data Objects) is a object-oriented data access interface to ODBC combined with the easy-to-use style of DAO, Providing an interface this exposes virtually all of ODBCS low-level power and flexibility. RDO is limited, though, into that it doesn ' t access Jet or ISAM databases very-so, and that it can access relational Datab ASEs only through existing ODBC drivers. However, RDO has proven to is the interface of choice for a large number of SQL Server, Oracle, and other large relational Database developers. RDO provides the objects, properties, and methods needed to access the more complex aspects of stored procedures and compl Ex ResultSets.

The ADO is the successor to Dao/rdo. Functionally ADO 2.0 is most similar to RDO, and there ' s generally a similar mapping the between two. ADO "flattens" the object model used by DAO and RDO, meaning this it contains fewer objects and more properties, methods ( and arguments), and events. For example, ADO has no equivalents to the Rdoengine and Rdoenvironment objects, which exposed the ODBC driver Manager and HENV interfaces. Nor can you currently create ODBC data sources from ADO, despite the fact that your interface The is might the ODBC OL E DB service provider.

Much of the "functionality contained in" DAO and RDO models was consolidated to single objects, making to a much simp Ler object model. Because of this, however, and might initially find it difficult to find the appropriate ADO object, collection, property, method, or event. Unlike DAO and RDO, although ADO objects are hierarchical, they are also creatable the scope of the outside.

It should be noted, however, which ADO currently doesn ' t support all of DAO ' s functionality. ADO mostly includes Rdo-style functionality to interact with OLE DB data sources, plus remoting and DHTML technology.

In general, it's probably too early in the evolution of ADO to migrate most DAO applications (except possibly ones using O Dbcdirect to ADO right now, since ADO doesn ' t currently support data definition (DDL), users, groups, and so forth. If you use DAO only for client-server applications and Don t rely on the Jet database engine or use DDL, however, then Can probably migrate to ADO now. Eventually, Microsoft would provide an ADO DDL component to aid in Dao-to-ado migration and provide DDL generic for OLE DB providers.