Difference between DAO and ADO when to use the them

[mls via AccessMonster.com]

I just know very little about these object libraries can some one elobrate
these..

If I check both ADO and DAO in my tool reference does this effect anyt hing?
aslo if at all I have to use ADO which library should I check b/w 2.1 to 2.8?
Thanks

 

[Daniel Pineault]

Search the programming forum for this subject to get information.

Also, see these posts as they ask exactly the same question
http://www.microsoft.com/office/com...a&p=1&tid=d7fd1c2e-39d0-4b1a-a114-9ce881b2961
http://www.microsoft.com/office/com...a&p=1&tid=b444e767-ee7f-423e-9da8-b7f70fbb960
http://www.microsoft.com/office/com...&p=1&tid=8370231c-f3ba-47ff-a124-fa05260068a7
--
Hope this helps,

Daniel Pineault
http://www.cardaconsultants.com/
For Access Tips and Examples: http://www.devhut.net
Please rate this post using the vote buttons if it was helpful.

 

[Dorian]

You can use DAO or ADO or both.
ADO is a later technology though some people say DAO is more efficient.
You need the correct reference to be able to use either.
I usually check the most up-to-date reference version. However, if you
distribute your application, make sure that every user has that version on
their PC.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".

 

[Jack Leach]

IMHO:

DAO is the native model for working with Access. The rule that I follow?
Unless you need ADO specifically, stick with DAO. I work entirely within
Access (and some minor automation with other applications in the Office
suite) and have never had a specific need to use ADO.

DAO is an extemely stable model. It has been on v3.6 for I don't know how
long now. ADO has gone through many many revisions, and keeping this
straight in user's apps if you don't have to can be a lot of extra work.

However, if you are connected to outside (non-native) data sources, you will
need ADO.

If by chance you have both references checked, be absolutely sure to
completely disambiguate everything. Instead of Dimming a Recordset, dim a
DAO.Recordset or ADO.Recordset. They are two entirely different things, with
different methods and properties.

This is not to say that ADO is no good... there's functionality you can get
from ADO that you have to work miles around to get from DAO.

Anyway, as the links Daniel gave, this is a topic to warrant much
discussion. I just thought I'd throw my two cents in!

hth


--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

 

[Allen Browne]

My experience agrees with Jack's.
Use DAO if your data is stored in Access (JET) tables.

For examples of working with each of these libraries, see:
http://allenbrowne.com/tips.html#Examples by Library

michka has a post on
What does DAO have that ADO/ADOx/JRO do not?
at:
http://blogs.msdn.com/michkap/archive/2007/07/13/3849288.aspx

 

[David W. Fenton]

ADO is a later technology though some people say DAO is more
efficient.

ADO is not a "leter technology" except in the sense that it was
created after DAO already existed.

At this point, DAO is the more recent, since it is being updated for
use with ACE (though the Jet 4.0 version, i.e., DAO 3.6, is not
being updated any longer).

As to efficiency, DAO will always be more efficient with Jet/ACE
data because DAO is Jet/ACE's native data interface. ADO may or may
not be more efficient for other data stores (as compared to DAO used
with Jet/ACE using ODBC).

In general, ADO is not needed in an Access app at all. DAO should be
the default choice until an actual use case for ADO comes up for the
app in question. By that, I mean you need to do something in the app
that DAO doesn't do, or that ADO does much more efficiently. With a
Jet/ACE back end, there are almost no such tasks that would be
commonly used in an Access app. For SQL Server, it's more common to
have some ADO sprinkled throughout your app because of the
limitations of using stored procedures and other server-side
objects. For other back ends, I wouldn't know, as I have only ODBC
experience with them.

 

[David W. Fenton]

If I check both ADO and DAO in my tool reference does this effect
anyt hing? aslo if at all I have to use ADO which library should I
check b/w 2.1 to 2.8?

Why are you checking off things that you don't understand?

You either need ADO or you don't. If you *do*, you'll know it. If
you haven't needed it, then don't check the reference.