ADO or DAO or ???

  • Thread starter Thread starter TC
  • Start date Start date
T

TC

Few of the "basics" for new Access programmers here (aka ME! ).

Can someone tell me what the difference between ADO, DAO and OLE ODBC ? I
understand that ADO or DAO is now considered "obsolete" ?
Click to expand...

ADO and DAO are each a set of "objects, methods and properties" for
accessing a database. ADO is the later one, DAO the earlier one. DAO was
commonly used for Access 97 & below. Microsoft took steps to enciourage
people to use ADO for Access 2000 & later, but you can still use DAO
instead, or as well. Certain features of DAO were unaccountably omitted from
ADO. It is not really true to say that either of them is "obsolete".
What does the typical command to access a recordset look like?
Click to expand...

If you really do mean a "recordset", in the true technical sense of that
term, there is no "command" to access one. You use appropriate objects,
methods & properties to create and access a recordset. In DAO:

dim db as database, rs as recordset ' <- objects
set db = currentdb()
set rs = db.openrecordset ("SELECT * FROM MyTable")
with rs
while not .eof ' <- property
debug.print .fields(0).name; "="; .fields(0).value
.movenext ' <- method
wend
end with
set rs=nothing ' <- statement
set db=nothing

Why would I choose to use these command within an Access database?
Click to expand...

How long is a piece of string? There are thousands of different reasons why
you might want to access a recordset. That's like asking, "Why would I want
to drive somewhere in my car?"

HTH,
TC
 
Few of the "basics" for new Access programmers here (aka ME! ).

Can someone tell me what the difference between ADO, DAO and OLE ODBC ? I
understand that ADO or DAO is now considered "obsolete" ?

What does the typical command to access a recordset look like?

Why would I choose to use these command within an Access database?

I have two books that I am reading now but when you hit the sections of
ADO/DAO - both authors assume that you understand this stuff already. The
chapters are NOT geared to new people like myself - it gets very frustrating
sometimes.

Thanks
Alan
 
I have heard that as long as you are only dealing with data within Access
there is a considerable performance advantage in using DAO. Any comments on
this anybody?
 
Alan said:
Few of the "basics" for new Access programmers here (aka ME! ).

Can someone tell me what the difference between ADO, DAO and OLE ODBC ? I
understand that ADO or DAO is now considered "obsolete" ?
Click to expand...

No, It is not obsolete. I use both DAO and ADO in my program. The reason is
whenever you want to access records in your bound form, MS Access always (as
far as I know) return DAO's recordset. But with DAO, You can not edit DAO's
recordset programmatically if that recordset is already opened thru another
form. But ADO can do that. You will love MS Access until you are trying to
develop the multiusers program. Test locking as much as you can ,
programmatic vs programatic, bound form vs bound form, prgoramatic vs bound
form. Otherwise, You may cry if you found record is not locked as you think
(or as it written in Help file).

For my opinion, If you develop program for commercial or want to invest for
a long term, It is better to use other development tools. MS Access have a
lot of problems. Not because of bugs (Yes, it has a lot also) but because
the way it was designed. More project size, It's less RAD.
What does the typical command to access a recordset look like?
Click to expand...

I think your books show many of example code already.
Why would I choose to use these command within an Access database?
Click to expand...

MS Access use VB as its native language. VB has no built-in command to
access data in database. VB has only command for manipulate flat-file under
Windows system. To access data in database, VB have to use command from
other libraries. In this case, It is ADO or DAO. Library can be added into
your project (In VB editor, click Tool>Reference). With this design, VB is
extensible.
I have two books that I am reading now but when you hit the sections of
ADO/DAO - both authors assume that you understand this stuff already. The
chapters are NOT geared to new people like myself - it gets very
frustrating sometimes.
Click to expand...

DAO is more simple and easier to understand than ADO. To start learning,
Look at hierachy of DAO model in MS Access help file will help you
understand more. Each level of hierachy is Collection (a group of objects)
or Object. Your command always in the format of [collection].object.method
or [collection].object.property. That is before you can use method (to do
something) or property (to get/set value) you have to track back what object
you have to use and how can derive that object.
 
Rod said:
I have heard that as long as you are only dealing with data within Access
there is a considerable performance advantage in using DAO. Any comments on
this anybody?
Click to expand...

Not only is that true, but I have yet to see any hard evidence that there
are significant performance advantages to ADO when *not* using Jet tables.
 
What would be the difference in coding if working in ADO?


***********************
If you really do mean a "recordset", in the true technical sense of that
term, there is no "command" to access one. You use appropriate objects,
methods & properties to create and access a recordset. In DAO:

dim db as database, rs as recordset ' <- objects
set db = currentdb()
set rs = db.openrecordset ("SELECT * FROM MyTable")
with rs
while not .eof ' <- property
debug.print .fields(0).name; "="; .fields(0).value
.movenext ' <- method
wend
end with
set rs=nothing ' <- statement
set db=nothing
***************************

Laura TD
 
Sorry, don't know. I've not used ADO.

TC


laura said:
What would be the difference in coding if working in ADO?


***********************
If you really do mean a "recordset", in the true technical sense of that
term, there is no "command" to access one. You use appropriate objects,
methods & properties to create and access a recordset. In DAO:

dim db as database, rs as recordset ' <- objects
set db = currentdb()
set rs = db.openrecordset ("SELECT * FROM MyTable")
with rs
while not .eof ' <- property
debug.print .fields(0).name; "="; .fields(0).value
.movenext ' <- method
wend
end with
set rs=nothing ' <- statement
set db=nothing
***************************

Laura TD

?
Click to expand...
 
There is no reason to use ADO with the (default) Jet database engine. DAO is
the native language of Jet, it is faster than ADO with Jet, and it is more
complete than the combination of ADO and ADOX. Further, it has (outside
Microsoft Office) already been superceded by ADO.NET which is built on a
different object model, so doesn't give you a headstart on the future.

And, we hear anecdotal evidence that for Access clients to server databases,
it may have little, if any advantage over Jet, DAO, and ODBC, if the user
audience is "modest" in size. Where it appears to have a performance
advantage is with server databases that have an ADO data provider, using an
Access project with MS SQL Server, and in accessing certain non-Access data
(XML tables, etc.).

You can create a recordset in ADO and "disconnect" it from the underlying
tables, so that updates to the recordset aren't automatically applied to the
source tables. This can, I am told, be advantageous in some circumstances;
however, I seem not to have suffered from not having this capability using
Access since 1993.

Larry Linson
Microsoft Access MVP
 
If dealing with Access, I recommend using DAO. ADO would
be more useful if you were to connect to a "non-
traditional" database, such as a text file or an Excel
workbook.
 
Thanks for the explanation, much appreciated and always something which I
have found very confusing (being a newbie). Why is it that sometimes we have
to say

dim rs as dao.recordset

Why is it necessary to add the "dao"?

Thanks
Laura TD
 
laura said:
Thanks for the explanation, much appreciated and always something which I
have found very confusing (being a newbie). Why is it that sometimes we have
to say

dim rs as dao.recordset

Why is it necessary to add the "dao"?
Click to expand...

It's only necessary if your file has references to both the ADO and DAO
libraries. In that case you have to disambiguate all objects that exist in
both libraries so your program knows which type of object you actually
want. Since Recordset exists in both DAO and ADO you need the prefix. I
don't know the whole list, but there are about a half dozen objects that
are common to both models.

If you remove the reference to ADO and leave the one for DAO then the
"dao-dot" is not required.
 
If you remove the reference to ADO and leave the one for DAO then the
"dao-dot" is not required.<<

Great, I think that in all the confusion about DAO and ADO, I had both
libraries selected, not really knowing why. I probably never needed the ADO
then.

Many thanks for clearing this one up for me.

Laura TD
 
Back
Top