DAO vs ADO

  • Thread starter Thread starter Gary S
  • Start date Start date
G

Gary S

I have a general question about DAO vs ADO.

It is my understanding ADO is the way to go and
DAO will eventually not be supported. But when
I look at coding examples at various web sites
that give examples of code, it is usually DAO.
Am I mistaken about DAO phase out? Please help me
understand.
 
DAO is alive and well. It was pushed a couple of versions ago, but came back
because of its popularity and ease of use.
Others may have different opinions, but I prefer DAO. It seems more
natuaral to me.
 
As Dave mentioned, DAO is alive and well. In fact, it's ADO that's no longer
supported: it was replaced by ADO.Net, which is quite different (and which
can't be used by Access).

DAO was designed specifically for use with Jet databases (i.e.: mdb, mde,
accdb or accde files). ADO, being a generic interface, isn't as quick (nor
as capable) in that situation, although it might make sense if you're
connecting to other DBMS.
 
Gary said:
I have a general question about DAO vs ADO.

It is my understanding ADO is the way to go and
DAO will eventually not be supported. But when
I look at coding examples at various web sites
that give examples of code, it is usually DAO.
Am I mistaken about DAO phase out? Please help me
understand.
Click to expand...

Access + ADO = New Coke
 
As Dave mentioned, DAO is alive and well. In fact, it's ADO that's
no longer supported: it was replaced by ADO.Net, which is quite
different (and which can't be used by Access).

DAO was designed specifically for use with Jet databases (i.e.:
mdb, mde, accdb or accde files). ADO, being a generic interface,
isn't as quick (nor as capable) in that situation, although it
might make sense if you're connecting to other DBMS.
Click to expand...

On top of both those points, DAO is under current, new development
since A2K7's introduction of Jet 5, AKA ACCDB.

So, the data interface layer with the ongoing future is DAO, not
ADO.
 
LOL
riding around in my Ford Edsel, wearing my Naru jacket, drinking New Coke.

Great analogy, Rick.
 
Doug,
You mention it might make sense to use ADO
over DAO when connecting with certain dbms,
does that include SQL Server?
--
Thanks for your help!
Gary S


Douglas J. Steele said:
As Dave mentioned, DAO is alive and well. In fact, it's ADO that's no longer
supported: it was replaced by ADO.Net, which is quite different (and which
can't be used by Access).

DAO was designed specifically for use with Jet databases (i.e.: mdb, mde,
accdb or accde files). ADO, being a generic interface, isn't as quick (nor
as capable) in that situation, although it might make sense if you're
connecting to other DBMS.
Click to expand...
 
Depending on how you're connecting to SQL Server, yes, it might make sense
to use ADO.

I've written applications where my communication to SQL Server was all done
through pass-through queries: no linked tables. Since pass-through queries
are not updatable, I used ADO to run the Update, Delete and Append queries
to update the database.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)


Gary S said:
Doug,
You mention it might make sense to use ADO
over DAO when connecting with certain dbms,
does that include SQL Server?
Click to expand...
 
Douglas said:
Depending on how you're connecting to SQL Server, yes, it might make
sense to use ADO.

I've written applications where my communication to SQL Server was
all done through pass-through queries: no linked tables. Since
pass-through queries are not updatable, I used ADO to run the Update,
Delete and Append queries to update the database.
Click to expand...

But you can also use passthroughs to do all of those things.
 
Rick Brandt said:
But you can also use passthroughs to do all of those things.
Click to expand...

True, but I found it easier to use the ADO Command object to run the stored
procedures.
 
I would have posted this sooner, but i've been busy mounting my brand new VHF
antena on the roof so that I get the new Dumont Network Affiliate....
 
Similar to Doug, I've also found it easier to go with ADO, particularly when
working in an ADP. Plus it has a few options that at least the old DAO
didn't...not sure about any newer versions that may have come out with
Access 2007. (Options such as asynchronous data access and on-the-fly
filtering & sorting without creating a new recordset come to mind.)

That said, ADPs, while perhaps not dead (debates still come up once in a
while on that subject), are certainly not on the forefront of Microsoft's
collective mind any more, and as has been mentioned, neither is the non-.Net
version of ADO.

DAO is definitely faster and more powerful in the end, though, and for
working with Jet data, I wouldn't recommend anything else, particularly if
speed is a concern. That said, I found ADO to be much more of a pleasure to
work with, especially when we switched to SQL Server and the speed of the
link far outweighed the speed of the data access library being used.

That's my two cents, take it or leave it.



Rob
 
Back
Top