From: klar on
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.
From: Bob Barrows on
klar wrote:
> 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?
>
They are both equally "readable". DAO can do a few more things with a Jet
backend (.mdb) than can be done with ADO, so my preference would be DAO.


From: Douglas J. Steele on
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(a)gmail.com> wrote in message
news:983515f6-2bdd-40a1-9141-9ca1cf410945(a)h8g2000prn.googlegroups.com...
> 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.


From: David W. Fenton on
"Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in
news:i1k7h9$dbo$1(a)news.eternal-september.org:

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

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/
From: Banana on
On 7/14/10 11:23 AM, David W. Fenton wrote:
> 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.

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).

 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: A Totals query problem
Next: Help with table design