DAO vs ADO

[Stevie]

I've been reading around some sites about this, and seem to get conflicting information wherever I read.

Can I hear some views on when to use ADO and when to use DAO.

I've heard the "Use ADO for all new development" statement plenty of times but what are the advantages?

From tests I have carried out DAO seems to be quicker than ADO when using Access.

[simonm]

DAO is probably faster for dealing with Access databases but using DAO you are tied to an Access database. If, in future you wish to chagne database, your code will no longer work.

With ADO, your code would probably not even need to change.
All you would have to do is ready the data provider for the new database you are using and change your connection string. (N.B. There is some functionality that is provider specific).

There are some features that ADO has and DAO doesn't; such as disconnected, shaped and constructed recordsets.

It's supposed to have a simpler object model as well (flat instead of heirachical) though t hat is a matter of opinion.

Microsoft will probably stop supporting DAO eventually and will not add new functionality to it whilst continuing to improve ADO.


I hope that answers your questions.

Simon

[JHausmann]

A solid reason for using ADO over DAO will depend on your choice of DBMS.

For SQL server, the drivers are newer and, in some cases, more efficient. You can also control things (connection/query timeout for example) that you cannot with other access methods.

[bar]

DAO will be phased out within the next couple of versions of VB, while ADO is getting better with each new release.

Also ADO is scalable. Changing from an Access database to SQL server or any other provider for that matter is as simple as changing your ODBC connection to the new provider. No code changes necessary. That is provided you use exactly the same database structure.

[alex_read]

DAO is probably faster for dealing with Access databases

is definitley right, DAO is much simpler and easier to work with, most developers I would think use this, as it has been the standard for vb'ers for the past 2-3 years and everyone seems to start learning with this.

However, give it 1 - 1 1/2 years & this will be Kaput/gone/kicked the bucket. I would 110% reccomend you learn ADO, as this is the new standard (which is moving again over to ADO+ - a newer standard for the web being introduced with vb7 (or vb.net)) - I have been considering all of the angles here and have read loads up on this as I don't want to learn ADO after the amount of time I spent doing DAO, but think I have to.

Trust me here - go ADO!

[Stevie]

I have written quite a few applications with DAO and ADO, but have never really questioned why I should use either.

I know all new development would be best in ADO for plenty of reasons from DAO being phased out to making it easy to swap the database type.

The thing is I'm working for a new company where they use quite a few Access databases (for the moment) which are very large, where I am used to working with smaller databases. I have written my last couple of apps with ADO, but now I have to consider the speed implications and from what I can see DAO is much better. Saying that, one day they will want to move to SQL Server, so I would be better off using ADO in that respect.

The conclusion I have come to is to use DAO if connecting to a local Access database, but if I connect to a remote database then I think ADO is the best option.