Chris said:
I think that is unusual. ADO was a "failed" replacement for DAO, or at least
for an Access-only installation. I can't enumerate the reasons to use both, so
it's for you to find some.
Like fish in a barrel... said:
If your clock stopped in 2002 then for you the official line is, "(DAO)
was the primary data access method. That has now changed. Although DAO
is still supported, the new way to access data is with ADO." I always
suspected DAO advocates were stuck in a time warp <vbg>.
For those of who are thinking of the future being Access 2007, DAO is
back in favour. However, to be frank, if you think ADO was a failed
experiment, you've got you've also got your head stuck in the sand.
Even in its Office 2007 incarnation, DAO still hasn't caught up with
ADO in terms of functionality i.e. properties, methods and events; why,
it still hasn't even got support for all the Jet 4.0 functionality!
Think about it: ADO was built on the success of DAO and learned from
its failings.
In a nutshell, there are things that you can do with ADO that you can't
do with DAO (similarly, there are things that DAO can do that ADO
can't; the vast majority can be achieved using either).
There are far too many things to 'enumerate' but let's briefly consider
the recordset. Things I can achieve with an ADO that I cannot with a
DAO recordset (and that I regularly use) include: disconnected
recordsets; persisting recordsets on disk (including XML format) which
can subsequently be reopened and used to update the source, using the
SHAPE syntax to create hierarchical recordsets; fetch records
asynchronously, using events such as _FetchProgress to be able to give
user feedback via a progress bar; paging using the PageSize,
AbsolutePage.
Generally, I find ADO a better coding experience: not having to
navigate the last record to be able to get an accurate record count;
easy to debug (e.g. the GetRows method can specify a subset of fields,
the GetString method, etc); flatter hierarchy allows a recordset to be
created without first explicitly creating a connection object, etc.
And this is just recordsets, off the top of my head and things I
actively use.
Actually, that last one reminds me why I am averse to DAO i.e. its
appalling teardown code which gave VBA a bad reputation is
unforgivable...
I can't deny, however, that the smart approach is to use both DAO and
ADO selectively, to take advantage of their relative merits. You may
not agree but then someone who can't see any merit in ADO may not be
the best judge.
One would need to value the prize, a Universal Subscription including the
latest Access!!!
It's better than that, I think: one MVP once mentioned a free MSFT
wristwatch said:
I think you should
contribute more.
I'm a 'quality, not quantity' person, myself. I probably put in at
least one hour per day on posting replies, though.
Jamie.
--
