DAO vs. ADO

[Guest]

Thanks for taking the time to read my question.

What are DAO, and ADO, and what are the differences and uses?

Thanks,

Brad

 

[Baz]

Thanks for taking the time to read my question.

What are DAO, and ADO, and what are the differences and uses?

Thanks,

Brad

DAO = "Data Access Objects"
ADO = "ActiveX Data Objects"

Both of them comprise a set of objects to help programmers query and
manipulate databases (relatively) easily. For example, they allow the
programmer to retrieve data from a database in the form of a recordset, to
navigate within such a retrieved recordset, and to add, modify and delete
records.

They are in many respects very similar. ADO is the newer technology, has a
lot more bells and whistles, and was introduced with great fanfare a few
years ago, first becoming available in Access with Access 2000. However,
many Access programmers consider that, for working with Access/Jet
databases, DAO remains the superior technology. Since Access 2000,
Microsoft has kindly provided a reference to ADO by default, but no
reference to DAO. Some of us reverse this as our very first step in a new
Access database i.e. remove the reference to ADO and add a reference to DAO!

Those who work with server database engines, e.g. SQL Server, often like
some of ADO's features that are not present in DAO, although it is certainly
perfectly possible to work entirely in DAO even with a server database.
However, if working in an Access ADP, you don't really have much choice, ADO
is the only real option.

You should also be aware that, much trumpeted as it was at it's launch, ADO
is now obsolete! It has been superseded by the entirely different ADO.Net.
However, ADO.Net is not, at this time, available to Access developers.

 

[Allen Browne]

DAO (Data Access Objects) is the library that was designed for Microsoft
Access, the library Access itself uses. It has been present since version 1,
and is still the best library to use if you store your data in Access tables
and write VBA code in Access.

ADO (ActiveX Data Objects) is a flash-in-the-pan alternative that was
introduced in Access 2000 in an attempt to support other alternatives (such
as disconnected recordsets), but is now effectively dead (replaced by the
completely different ADO.NET technology.)

If you are planning to develop in Access, using Access tables, forms, and
VBA code, learn DAO. For a basic introduction to the objects exposed by this
library, see:
DAO: Data Access Objects
at:
http://allenbrowne.com/ser-04.html

For an explanation on how to set up to use ADO or DAO references in your
code, see:
http://allenbrowne.com/ser-38.html

 

[Guest]

Hi, Brad.

The DAO and ADO Object Libraries are libraries written to allow us to access
data from whatever source the data is currently stored in. DAO stands for
Data Access Objects and ADO stands for ActiveX Data Objects. DAO is the
older object library that Microsoft replaced with ADO, but later realized
that DAO is better for accessing Jet databases, so recommends using DAO now.

The DAO library was designed to work with Jet databases and using ODBC and
drivers, can connect to other types of databases and work with those data
sets as well in a heterogeneous environment. The DAO library handles
database connections, data sets, record locking and transactions. It also
can manipulate the Jet Database Engine Object and can handle Jet's User-Level
security.

The ADO is a generic library to handle database connections, data sets,
record locking and transactions. It has several features that are
unavailable in DAO, such as disconnected recordsets, but one may never need
these features.

Please see the following Web page for the MichKa's (Michael Kaplan, former
Access MVP) list of things that DAO has that ADO doesn't have:

http://www.trigeminal.com/usenet/usenet025.asp?1033

Both Access 2000 and Access 2002 have the ADO library set as the default
data access library -- which causes problems to this day -- but thankfully,
Microsoft saw the wisdom of setting the DAO library as the default library
for data access, so this is what newly created databases in Access 2003 and
pre-Access 2000 versions have.

If you are going to be programming Access's objects and data, then I'd
recommend that you learn DAO ASAP. If you only need enough programming
skills to connect to external non-Jet data sources, then ADO is fine.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address so that a message will
be forwarded to me.)
- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.

 

[Guest]

Thanks to all for the replies.

I have been using 97 until now, so I guess I am familiar with DAO. I
thought I would have to learn ADO... guess not.

I'll set my DB to DAO, and take out the ADO.

Thanks agian,

Brad

 

[Baz]

Thanks to all for the replies.

I have been using 97 until now, so I guess I am familiar with DAO. I
thought I would have to learn ADO... guess not.

I'll set my DB to DAO, and take out the ADO.

Thanks agian,

Brad

A wise decision!

 

[Marshall Barton]

What are DAO, and ADO, and what are the differences and uses?

You will probably get different opinions from different
people, so I thought I's toss mine into the fray ;-)

DAO is the native library for use with the Jet database
engine (i.e. an MDB data file). Since it was designed for
this purpose, in this context, it is generally more complete
and more efficient than other approaches.

The ADO library was designed as an interface to other
database engines such as SQL Server, Oracle, etc. I think
it may be the preferred approach when you're working with an
ADP project, but there may be some question.

If you have read somewhere that ADO is the "wave of the
future" and DAO is dead, don't believe it. From everything
I've heard, DAO is still evolving.

 

[Douglas J. Steele]

Since Access 2000,
Microsoft has kindly provided a reference to ADO by default, but no
reference to DAO. Some of us reverse this as our very first step in a new
Access database i.e. remove the reference to ADO and add a reference to
DAO!

Actually, Access 2003 has both, but the ADO reference is higher in
precedence than the DAO one.

Still a good idea to remove the ADO reference if you aren't going to be
using it.

 

[David C. Holley]

Keep in mind that since ADO was/is intended for use with a variety of
databases, its has to by default be more generic. As someone else
pointed out, if you're using anything that Access would use JET by
default go with DAO.

 

[Douglas J. Steele]

If you have read somewhere that ADO is the "wave of the
future" and DAO is dead, don't believe it. From everything
I've heard, DAO is still evolving.

ADO is dead: it was replaced by ADO.Net, which other than the first 3
letters is nothing like ADO.

DAO, on the other hand, is definitely alive: the Access development team now
owns the database engine again (Jet had become part of the operating
system), and Office 12 will have a new version of DAO.

 

[Jesper Fjølner]

DAO, on the other hand, is definitely alive: the Access development team

now owns the database engine again (Jet had become part of the operating
system), and Office 12 will have a new version of DAO.

That sounds exciting. It's hard to come by news of what we can expect from
Access 12.
Does anyone have any rumors or insight?

 

[Marshall Barton]

That sounds exciting. It's hard to come by news of what we can expect from
Access 12.

You can google for "Office 12" to find out what has been
announced.

For more inside scoop, you may want to keep an eye on the
recently created blog at http://blogs.msdn.com/access/

 

[Baz]

Actually, Access 2003 has both, but the ADO reference is higher in
precedence than the DAO one.

Still a good idea to remove the ADO reference if you aren't going to be
using it.

So I discovered from another post. I hadn't thought about it before, but
looking back it seems that I've only done ADP's with Access 2003!

Thanks! Learn something new every day around here!

 

[Douglas J. Steele]

That sounds exciting. It's hard to come by news of what we can expect from
Access 12.
Does anyone have any rumors or insight?

They're starting to blog at http://blogs.msdn.com/access/

There's also stuff at http://www.microsoft.com/office/preview/default.mspx

 

[Jesper Fjølner]

DAO, on the other hand, is definitely alive: the Access development team

You can google for "Office 12" to find out what has been
announced.

For more inside scoop, you may want to keep an eye on the
recently created blog at http://blogs.msdn.com/access/

That's sounds very exciting with the altered JET engine!

 

[david epsom dot com dot au]

Also,

ADO was the OLEDB replacement for RDO and ODBCdirect,
which were ODBC connectors.

ODBC (Open DataBase Connectivity) was a standard defined
using a Windows API interface

OLEDB (Object Linking and Embedding DataBase) was a
standard defined using a Windows OLE interface.

RDO and ODBCdirect allowed you to connect to any
database for which someone had written an ODBC
interface.

ADO allowed you to connect to any database for which
someone had written an OLEDB interface.

DAO allowed you to connect to any database for which
Microsoft had written a Microsoft Jet interface.

There were always many more connectors written for
the open standards than the few written by MS for
the private Jet interface.


Just to confuse things, there is an OLEDB interface
for ODBC, and a Jet interface for ODBC, and ODBC and
OLEDB interfaces for Jet, so you can get from almost
anywhere to almost any database.

(david)