Latest on ADO vs. DAO

[David Portwood]

I've been getting conflicting info about this. Sometimes I read that DAO is
dead like the dinosaurs, and sometimes I read that ADO has problems (poor
performance relative to DAO) and DAO will return and ADO will die out.

My one and only app was developed using DAO. I could change my code to use
ADO. Should I? Does it matter?
Right now the office uses A2000 but we will be upgrading to A2003 soon.

 

[Douglas J. Steele]

If all you're doing is using a Jet database (i.e.: your data is in an MDB or
MDE file), DAO is the better approach. DAO was written specifically to deal
with Jet databases, whereas ADO is a more generic approach (meaning that you
have to go through more layers of abstraction, meaning that it's less
efficient).

If you might move to another DBMS at some point in the future (say, using
your Access application as a front end to SQL Server or Oracle), you might
consider moving to ADO. However, simply changing the Connection property to
the new value doesn't mean that your application will be as efficient as it
could be, so you may not actually be buying anything unless you do a rewrite
of your application.

 

[Arvin Meyer [MVP]]

Would learning that ADO had been deprecated in favor of ADO.NET (which won't
work in an Access front-end) influence your decision. The dinosaur here is
ADO. I suspect it will continue working for some time because of all the
existing code running in it. That said, I've always used DAO for most
things, and I will continue to do so.

 

[Tony Toews [MVP]]

I've been getting conflicting info about this. Sometimes I read that DAO is
dead like the dinosaurs, and sometimes I read that ADO has problems (poor
performance relative to DAO) and DAO will return and ADO will die out.

My one and only app was developed using DAO. I could change my code to use
ADO. Should I? Does it matter?
Right now the office uses A2000 but we will be upgrading to A2003 soon.

Unless you have a compelling reason to change I wouldn't bother. DAO
works well in Access 2007 as well as A2003. And I do not know of any
compelling reason to spend the effort with nothing to show for your
work.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

Would learning that ADO had been deprecated in favor of ADO.NET
(which won't work in an Access front-end) influence your decision.
The dinosaur here is ADO.

Which is no longer in development, and DAO, which was said at the
release of A2K to be dead, is now in active development again.

Don't believe *anything* MS says about which of its technologies are
dead. Instead, pick your technologies according to which works best.
MS now agrees with those of us who were paying attention back in
1999 and understood the issues that DAO works best in the most
situations.

That's not to say that ADO very useful in a large number of
instances. But when you're using Jet data, it has virtually no
place. If you're using SQL Server, then ADO has advantages, and is
the only way to go if you're creating an ADP. But MS is now
deprecating ADPs, so that's not necessarily the wave of the future
any more.

I would never learn a technology just because I thought I was going
to need it some day. If I'd done that based on MS's advice, I'd have
wasted weeks and months of time on technologies that ended up in the
dumpster.

 

[David Portwood]

Thanks for the insights. I'll stick with DAO methods unless and until I hear
about specific benefits from changing.