DAO v ADO

[Alan Reinhart]

I'm just starting to work with Acess 2003 (but have done other db work in
the past). I'm looking to do some modest projects involving extracting data
from a text report and turning into a properly nomralized database app.
First round would only be single users, but if interest grew the project
could easily move to a multi-user deployment. Maybe 10-15 users.

My big question: It would appear DAO should be adequate for this type work,
moreso if it stays as a single user app. But I'm getting the impression ADO
is the "wave of the future" (while you are thinking 'DUuuH!' you must
understaind I'm quite MS-impaired as well) - should I just bite the
complexity bullet and learn and use ADO right of the bat?

=Alan R.

 

[david epsom dot com dot au]

understaind I'm quite MS-impaired as well) - should I just bite

complexity bullet and learn and use ADO right of the bat?
Yes

My big question: It would appear DAO should be adequate for this

Not just adequate, superior for MDB databases

is the "wave of the future" (while you are thinking 'DUuuH!' you

Well, that wave has already crested. ADO.Net came next.


DAO is faster and easier for Jet/MDB databases. But:

It uses an object model that is unfashionable (using methods
of the parent to create children): It is optimised for a
database engine that must surely be replaced after Windows
'Longhorn' arrives in a few years time (Jet): It is unloved by
the supplier (Microsoft): And has been stabilised to only
support features available in the Office 97 release.


I definitely recommend DAO to all advanced Access programmers,
and there is no compelling reason to change existing applications.
but if you are interested about LEARNING and the FUTURE
rather than optimisation and the present, ADO is the way
to go.

(david)

 

[John Vinson]

My big question: It would appear DAO should be adequate for this type work,
moreso if it stays as a single user app. But I'm getting the impression ADO
is the "wave of the future" (while you are thinking 'DUuuH!' you must
understaind I'm quite MS-impaired as well) - should I just bite the
complexity bullet and learn and use ADO right of the bat?

In my opinion, in your circumstance - and many similar ones - DAO is
still the tool of choice. It's very efficient with JET (Access)
databases; it's actually a bit simpler than the ADO model in some
ways; and it's still needed in some circumstances (Forms still have
DAO recordsets as their record sources IIRC).

I use DAO extensively, and ADO only when I need ADO's features.

 

[Alan Reinhart]

David, John - Thanks for the confirmation of my thoughts.

A remaining question:

In Access 2003 Help Table of Contents there is a detailed reference to DAO
and the Jet Database. Is this material (as well as the other info in there)
available as a printed book?

If so can you point me to it?

=Alan R.

 

[Larry Linson]

but if you are interested about LEARNING
and the FUTURE rather than optimisation
and the present, ADO is the way to go.

I'm puzzled as to why you'd say this, david, because classic ADO's successor
ADO.NET is built on a different object model, and appears to share little
more than part of its name.

Larry Linson
Microsoft Access MVP

 

[david epsom dot com dot au]

ADO is stylistically more modern than DAO: I think it has more in
common with ADO.NET than with DAO. So far, all of my colleagues have
agreed. You're the first to say otherwise.

However, my personal exposure to ADO.NET is limited, and I may
change my mind after I have more experience.

(david)