Dear Access experts,

I have no experience writing ADO or DAO code but I am going to start
soon. After reading up on ADO and DAO, it seems both can do the job
for me. However, I do not know enough to know which one to choose.

I am using Access2003 and the database will be used locally, not on a
client-server environment. I will be mainly using ADO/DAO for queries.
My preferred choice is the one with more readable code. Can the
experts here advise me ADO or DAO?

Thank you very much.

klar wrote:
backend (.mdb) than can be done with ADO, so my preference would be DAO.

The issue shouldn't be which is more readable (they're pretty much the
same), but which is better.

From the sounds of it, you're talking about using strictly Jet databases
(i.e.: MDBs). That means you should use DAO.

--
Doug Steele, Microsoft Access MVP
http://www.AccessMVP.com/DJSteele
Co-author: Access 2010 Solutions, published by Wiley
(no e-mails, please!)

"klar" <klarbuf (AT) gmail (DOT) com> wrote

"Douglas J. Steele" <NOSPAM_djsteele (AT) NOSPAM_gmail (DOT) com> wrote in
news:i1k7h9$dbo$1 (AT) news (DOT) eternal-september.org:

It's not a matter of whether you're using an MDB or ACCDB to store
your data, but whether or not you're using Jet/ACE to access your
data. With MDB/ACCDB, its axiomatic that you're doing so. But it's
also the case that if you're accessing a different database engine
via ODBC, you're also using Jet/ACE, and in that case DAO is the
best choice.

So, use DAO for any MDB/ACCDB back end, or any back end accessed
through ODBC.

From where I sit, this basically means that you never use anything
but DAO as your default database interface, since there's no reason
why you'd be using anything other than MDB/ACCDB/ODBC.

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

On 7/14/10 11:23 AM, David W. Fenton wrote:
I'm reminded of the adage, "When the only tool you have in hand is a
hammer, everything looks like nails."

With a Jet backend, I very much agree that DAO is really the only tool
we need. With ODBC backend, there are already a lot of things we can do
even going through Jet that it's conceivable that we can build a good
front-end client using nothing but DAO. But would I go as far to say it
should be the *only* tool? No, not really. I do reach for ADO when there
is a specific need for it, and it has served me well in few cases where
DAO came up short. The cases are quite rare but when it does happen, I'm
glad to have the luxury of choosing a different data access technology,
even if ADO is dormant and superseded by newer technologies (in which I
also hope the Access team will remedy somehow).

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4C3E35C1.3010809 (AT) Republic (DOT) com:

I did not say that. I said "never use anything but DAO as your
DEFAULT DATABASE INTERFACE." That doesn't say "never use anything
else" -- it only says use DAO as the default until you need
something DAO can't do or doesn't do well, and then use the
non-default interface.

This is 100% consistent with what I wrote.

There is no contradiction between your practice and my principle as
I very carefully worded it. You read something different than the
plain sense of what I wrote, however.

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

How readable your code is depends entirely on your skills.

Both ADODB and DAO are made up of a conglomeration of objects
and collections of objects that you have to wade through in order
to do much of anything.

It's real easy to write ugly repetitive code using either.

Like David said, if the BE is MDB or an ODBC then I use DAO. If on the
other hand I want to be able to talk directly to a server at some
point in the future (scaling up) and really want performance then I
tend to dodge ODBC connections and instead use ADO to talk to the
database server directly. It really depends on the app that is being
built and the expected implementation - you can swap out an ADO
connection to a different DB type quite easily if you need to.

That being said, most of the stuff I write is DAO based as the
requirement for ADO really doesnt exist for most cases. Jet with DAO
works really well, its well tested and well understood. Keeping your
code clean is another matter entirely. If you compare the code
required to run a select query via DAO and ADO they are actually
pretty similar in both form and logic. Its not hard to translate
between them with a little practice.

For most things, in Access, I would suggest DAO if you need to do
code. You might also consider using queries and linked tables (for
external data like a Back End (BE) MDB file). Depends on your use
case, but I typically find they are fast, friendly, and reliable.

Cheers

The Frog

"The Frog" <mr.frog.to.you (AT) googlemail (DOT) com> wrote

I am using ADO and didn't know about DAO at all, so I used Google to find
some information. What I found on Wikipedia was among other things:

"DAO 3.6 was the final version developed by Microsoft. Microsoft says that
DAO will not be available in its future 64-bit operating systems."

Worth some attention?

Sven

On 7/15/10 2:47 AM, Sven Pran wrote:
I expect that if you follow the source back to the MSDN, you would find
that the declaration of deprecation would be for a completely different
context. It used to be that DAO and Jet was considered to be a part of
Windows and Access was basically the GUI layer to those technology. So
in a sense, you could basically run any Access .mdb on any Windows
computer even without Access installed as long your custom program used
DAO/Jet which is rare nowadays as programmers are more likely to use ADO
or OLEDB if the Jet is used as a data source nowadays. Note that they
may not even always choose Jet now that they also could use SQL Server
Compact Edition or SQL Server Express Edition (both are free) or even a
different embedded database program. I understand SSEE is the preferred
engine when wanting to do small scale web development for example.

But the above doesn't really apply in the context of Access development,
and more especially so that Access team also has privatized the
underlying technology since post-2003. When Access team took control of
those technology, - which I suspect is a part of reason why it was
named ACEDAO and ACE for DAO and Jet, respectively - they have been
actively developing those technology.

ADO, OTOH, is in maintenance mode since ADO.NET is designated successor
and has not had any active development though it continues to be
included in MDAC. I would actually expect ADO to diminish in
significance as time go by both in context of general programming and in
Access development.