DAO or ADO ?

[Rob Hofkens]

Hello everyone

I am using a SQLServer 2000 as backend and Access 2003 as frontend using a
lot of VB code.
The tables are linked through a DSN less connection.
Since I am still a begining user of Access I am still not sure when to use
DAO or ADO.
I have been doing some code in both and notice some significant differences
how to accomplish something.
I have read about it and came to the conclusion that ADO is going to be the
new standard and wonder if I should go for ADO all the way when I need to
use one of the two ?

Some good advice would be much appriciated !

Rob.

 

[Douglas J. Steele]

Well, I wouldn't assume that "ADO is going to be the new standard", since
it's already been replaced by ADO.Net, which has little resemblance other
than the first 3 letters, but...

It really depends on how you're interacting with SQL Server, but I usually
go with ADO against SQL Server and DAO against Jet (even when building in
Access 97). There's no problem mixing the two in a single application as
long as you're careful to disambiguate.

 

[Rob Hofkens]

Thank you for your advice !

Rob.

Well, I wouldn't assume that "ADO is going to be the new standard", since
it's already been replaced by ADO.Net, which has little resemblance other
than the first 3 letters, but...

It really depends on how you're interacting with SQL Server, but I usually
go with ADO against SQL Server and DAO against Jet (even when building in
Access 97). There's no problem mixing the two in a single application as
long as you're careful to disambiguate.

 

[onedaywhen]

Well, I wouldn't assume that "ADO is going to be the new standard", since
it's already been replaced by ADO.Net, which has little resemblance other
than the first 3 letters, but...

I don't consider ADO.NET a "replacement" for ADO classic and the reason
can be found in those first 3 letters of their respective names. The
letter 'A' in ADO classic stands for 'ActiveX'. The same is not true of
ADO.NET; MSFT simply carried over the ADO moniker because it was a
popular/successful 'brand' in the software development world. ADO.NET
is not built on ActiveX technology. Without a COM interop you cannot
use ADO.NET objects in a VBA project. So if ADO.NET is no *substitute*
for ADO (or DAO for that matter), in the objective meaning of the word,
then how can it be its replacement?

It depends what you want to do. There are some tasks that can only be
done in ADO and others that can only be done in DAO but the vast
majority of tasks can be achieved in both. Yesterday I wanted a
recordset for a hierarchical control so it seemed most natural to use a
hierarchical ADO recordset.

One thing to note is that ADO is build on the success of DAO (and RDO),
meaning it's objects are more flexible (e.g. you can create a Recordset
without a Connection object, you don't have to explicitly destroy
objects and in the correct order too, etc) and they support more
properties, methods and (introduce) events (e.g. ADO Recordsets can be
hierarchical/reshaped, fabricated, disconnected, persisted on disk,
used to execute/fetch asynchronously, used for paging, etc). The
Microsoft Office 2007 Access database engine Object Library (ACEDAO.DLL
or just plain 'DAO' in the Object Browser) does not seem to have
capitalized much on ADO's successful features.

Jamie.

--

 

[Rob Hofkens]

I don't know anything of ADO.Net but what I was afraid of was the support of
DAO in future releases of Access.
When my boss one day decides to upgrade MS Office, the last thing I want to
do is to rewrite the code I am creating now.

Rob.

 

[onedaywhen]

I don't know anything of ADO.Net but what I was afraid of was the support of
DAO in future releases of Access.
When my boss one day decides to upgrade MS Office, the last thing I want to
do is to rewrite the code I am creating now.

It looks like both ADO classic and DAO will be in Access 2007 and no
doubt in many versions to come, so I think you're safe either way.
Development of ADO classic has stopped, almost certainly for ever. DAO
stands better chance for future development however, as I said, DAO has
still not caught up with ADO classic as regards features and I doubt it
ever will

Jamie.

--