If your data is stored in Access tables, use DAO.
DAO is the native Access library.
The A in DAO *is* Access.
Access itself uses it (e.g. to run its queries.)
When Access 2000 was released, MS did try to get us to switch to the more
generic ADO. That's where the "outmoded" comments originated. Since that
time, ADO has become outmoded as a generic library, replaced by the quite
different ADO.NET.
In Access 2003, the DAO library reference came back as a default, and
continues to be so in Access 2007.
There may be reasons to use ADO if you are connecting to data data is other
sources, but if you use Access tables, DAO lives!
Here's some links that might help:
Libraries to use for different versions of Access:
http://allenbrowne.com/ser-38.html
Picture of the DAO object model:
http://allenbrowne.com/ser-04.html
25 DAO code examples:
http://allenbrowne.com/func-DAO.html
Comparison of the field names in the different libraries:
http://allenbrowne.com/ser-49.html

Signature
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
>I have two Access 2000 texts. One uses ADO (and says DAO is outmoded
>technology - is this true?) and the other uses DAO. I must say, the DAO
>commands seem less complicated, at least when it comes to opening a
>recordset.
don't use MDB for anything
and don't use DAO for anything
use SQL Server you f.cking dipshit
DAO hasn't been included with Windows, Office or MDAC for 10 years
SERIOUSLY
do the math
anyone using MDB or DAO should be fired and then spit upon
> If your data is stored in Access tables, use DAO.
>
[quoted text clipped - 36 lines]
> >commands seem less complicated, at least when it comes to opening a
> >recordset.
just because
DAO -> ADO -> ADO.net that doesn't mean that DAO is cool again
Office Web Components-- in Office 2003-- those don't support DAO.
RIGHT?
ADP in Office 2003-- that doesn't support DAO
so just because 1/3rd of Office _ALLOWS_ DAO that means that it's
suddenly the cool thing to do again?
STFU you f.cking newbie retards
only a f.cking retard in a wheelchair-- like michael kaplan-- who
doesn't have the mental capacity to learn SQL Server because he is
_RETARDED_
only Michael Kaplan should use DAO.. just because he doesn't have the
capacity to learn a new library
f.cking retards
lose the training wheels, dipshits
> If your data is stored in Access tables, use DAO.
>
[quoted text clipped - 36 lines]
> >commands seem less complicated, at least when it comes to opening a
> >recordset.
jim9 - 30 Jun 2007 03:38 GMT
You are the biggest mis-informed person I have ever read a post from. Now
let someone with ASP, ASP.NET, JAVA/JSP, PHP, ACCESS, VISUAL FOXPRO, ETC
experience tell the real story.
If using access only in one building on a network use DAO., case closed, no
discussion.
Else, use SQL SERVER or MYSQL OR DB2, OR ORACLE, OR SAP, OR ANY OF THE BIG
BACKEND DATABASES, and put your tables their. And for a frontend, if
intranet only, you can build an MS ACCESS frontend to it. If an internet
database, write a PHP, OR ASP.NET, OR JSP LANGUAGE frontend to the data
tables.
DAO is for single or networked computers, ADO is/was for server/intranet, ADO.
NET (USING C# OR VB.NET), OR PHP, OR JSP (any flavor ie., serverlets or not)
is for web/internet databases.
I get so tired of you people being confused about dao/ado.
And for everyones info, Access is still a very, very, very good networked
database. In 10 years of using one in a large trucking company, I only had
to restore a backup once. That's the key, backup.
>just because
>
[quoted text clipped - 26 lines]
>> >commands seem less complicated, at least when it comes to opening a
>> >recordset.
> If your data is stored in Access tables, use DAO.
>
> DAO is the native Access library.
> The A in DAO *is* Access.
Er, that would be *lower-case" access, not Access the Microsoft
product -- it's just the generic meaning of access, as in gaining
access to data.
> Access itself uses it (e.g. to run its queries.)
I'm not certain about that. At one point this came up in a
discussion with Michael Kaplan, and I think he said that Access
talks directly to Jet, rather than using DAO. If this were not so,
then there'd be no need for a DAO reference. It is true that some
objects that we think of as specifically belonging to DAO are
available without the DAO reference. For instance, CurrentDB and
DBEngine are all properties.methods of the Access Application
object, and available without any reference to DAO.
So, I wouldn't make the claim so strongly as you make it. Access
doesn't need an intervening layer to talk with Jet for certain
operations (remember after all that an MDB file, even a front end,
is a Jet database, and that much of Access itself is written in
Access itself, e.g., wizards and so forth).
> When Access 2000 was released, MS did try to get us to switch to
> the more generic ADO. That's where the "outmoded" comments
> originated. Since that time, ADO has become outmoded as a generic
> library, replaced by the quite different ADO.NET.
However, classic ADO is still quite useful for working with non-Jet
data, more specifically, SQL Server.
It's too bad MS completeley mucked up the ADO introduction in
Access. ODBC really is pretty outmoded as a database abstraction
layer, since it isn't up-to-date on a number of features that are
now widely supported in mainstream database engines.
> In Access 2003, the DAO library reference came back as a default,
> and continues to be so in Access 2007.
Does the default DAO in an ACE read legacy Jet data without
problems? That is, DAO is now somewhat more complicated, as there
are two distinct Jet database engines to support, the traditional
Jet 4.0 lineage, and the new fork for the ACE.
> There may be reasons to use ADO if you are connecting to data data
> is other sources, but if you use Access tables, DAO lives!
And is now under new development because the Jet database engine (in
its ACE incarnation) is once again in live development.

Signature
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/