adodb and dao

Hi adk77,

Some articles to read:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndao/html/daotoadoupdate.asp

http://www.thebestweb.com/db/dbaccesscode.asp

http://www.vbexplorer.com/vb_feature/june2000/Database_Beginner_ADO_DAO.asp

http://pages.about.com/vbmakai/ado0.htm

http://www.vbworld.com/articles/dbtutorial6/index3.html

http://www.utexas.edu/courses/poynor/access2000/sjdaoadorecordsets.html

http://www.orafaq.org/faqmsvb.htm

Have a look at:

http://www.thebestweb.com/db/dbaccesscode.asp

http://www.vbexplorer.com/vb_feature/june2000/Database_Beginner_ADO_DAO.asp

and

http://vb.oreilly.com/news/ado_0200.html

In short, DAO is the first technology given by MS, to access databases. This is specifically to access local databases, esp. MS Access.

To access remote databases, RDO, introduced after DAO.

The latest one for simpler usage, is ADO.

So, if you use adapting the new technology ADO, it is better. MS will be enhancing ADO in future versions of VB, and support provided to it, but for DAO no further enhancements made to it, though it will be there, still.
In many applications, dealing with Access, as you can see in the links above, DAO is faster, compared to ADO. But this one you can compensate to some extent, if I am right, by using direct SQL queries in ADO.

Hope it helps.

In short
If you are starting a project or learning this database connection model, use and learn ADO. You will benefit in the future when you learn more. If using on Win95/98 download ado 2.5 service pack1. It has a few bugs fixed and works pretty well.

Here's a comparison:

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

RDO (Remote Data Objects) is an object-oriented data access interface to ODBC combined with the easy-to-use
style of DAO, providing an interface that exposes virtually all of ODBC?s low-level power and flexibility.
RDO is limited, though, in that it doesn't access Jet or ISAM databases very well, and that it can access
relational databases only through existing ODBC drivers. However, RDO has proven to be 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 complex resultsets.

ADO is the successor to DAO/RDO. Functionally ADO 2.0 is most similar to RDO, and there's generally
a similar mapping between the two models. ADO "flattens" the object model used by DAO and RDO, meaning
that 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 might be through the ODBC OLE DB service provider.

Much of the functionality contained in the DAO and RDO models was consolidated into single objects,
making for a much simpler object model. Because of this, however, you 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 outside the scope of the hierarchy.

As you can see ADO is the most recent and combines the functionality of the other two.
Given a choice I would use ADO above either of the others just for its flexibility and simplicity.

Vin.