DAO vs. ADO

[Dataman]

I'm looking for some clarification from Microsoft about the future of DAO. I've been programming in Access of the past 12 years and have come to use both DAO and ADO. I have found that DAO works very well when interfacing with mdb objects. I know that Microsoft is not working on a new version of DAO, but does that mean that it will discontinue the use/support of DAO in the future? Is there a Microsoft white paper on this topic

Thanks
Mik

 

[Van T. Dinh]

Not sure of Microsoft direction but at present, ADO is more or less
superseded by ADO.NET.

I believe Access 2003 actually has DAO as the default Reference rather than
ADO which were the default Reference for Access 2000 and Access 2002.

--
HTH
Van T. Dinh
MVP (Access)

I'm looking for some clarification from Microsoft about the future of DAO.

I've been programming in Access of the past 12 years and have come to use
both DAO and ADO. I have found that DAO works very well when interfacing
with mdb objects. I know that Microsoft is not working on a new version of
DAO, but does that mean that it will discontinue the use/support of DAO in
the future? Is there a Microsoft white paper on this topic?

 

[Larry Linson]

Both DAO and the Jet database engine for which DAO is the native language
are "in maintenance mode" according to Microsoft. That is worse than it may
sound, because in Redmond-speak, it means not that "we fix only bugs" but
"we fix only ship-killing bugs" (those that would prevent shipment of some
other product). Despite this status, there have been 8 Service Packs to Jet
4.0, and some would consider a few of the changes in SP 7 and SP 8 to be
"more than bug-fixes".

There is so much Jet and DAO in use in database applications, by
individuals, small and large corporations, and (perhaps more importantly) by
giant enterprises, that Microsoft would draw a great deal of criticism if
they eliminated DAO or Jet from a release of Access in the next few years.
My personal prediction (no insider info) is that they are unwilling to deal
with that much criticism over this issue.

'Classic ADO' as used in Access certainly is not the "wave of the future".
Its successor, ADO.NET, which is even built on a different object model, is
already available in the .NET framework/languages/Visual Studio. But you
can't begin using ADO.NET in Access, because it isn't yet supported there.

As to what to use in the future, I guess we will just have to wait and see
what is available.

Larry Linson
Microsoft Access MVP

I'm looking for some clarification from Microsoft about the future of DAO.

I've been programming in Access of the past 12 years and have come to use
both DAO and ADO. I have found that DAO works very well when interfacing
with mdb objects. I know that Microsoft is not working on a new version of
DAO, but does that mean that it will discontinue the use/support of DAO in
the future? Is there a Microsoft white paper on this topic?

 

[John Vinson]

I'm looking for some clarification from Microsoft about the future of DAO. I've been programming in Access of the past 12 years and have come to use both DAO and ADO. I have found that DAO works very well when interfacing with mdb objects. I know that Microsoft is not working on a new version of DAO, but does that mean that it will discontinue the use/support of DAO in the future? Is there a Microsoft white paper on this topic?

Thanks,
Mike

Just FWIW, Microsoft isn't working on ADO either - everything is now
ADO.Net which has very little other than the first three letters in
common with ADO. The scuttlebutt (and I'm sorry but I can't give you
an authoratative cite) is that DAO will continue to be supported for
some time; there are a LOT of installed Access apps out there and MS
would be foolish to drop those customers.