David said:
Because it was COM-based and therefore had to be majorly revised to
work in .NET. Thus, classic ADO was orphaned.
The point of COM was to provide an interface, essentially handles into
the object model, including methods, of the COM enabled software. So
ADO and COM are both basically interfaces.
From:
http://en.wikipedia.org/wiki/Component_Object_Model
"However, COM objects can still be used with all .NET languages without
problems."
and
"It is likely that the characteristics of COM make it most suitable for
the development and deployment of desktop applications, for which it was
originally designed."
and
"These malware attacks mostly depend on ActiveX for their activation and
propagation to other computers."
So the point that COM has negatives for something meant to go beyond the
desktop has merit. When you think about it, opening up an interface to
the object model on the internet is akin to bringing back America's Wild
West. The fact that the ADO interface and ADODB have issues when
extended to the internet is a good reason to keep them from becoming
universal tools.
Why was it deprecated for general use in Access?
I don't know that it *is* deprecated, except for Jet data.
I agree that I should phrase that differently. As more users use SQL
backends, "general use" will mean something entirely different.
Why was it deprecated for Jet data?
Because it's bloody obvious that DAO is the superior interface for
Jet data.
I think we'll have to disagree on how obvious it was to Microsoft back then.
From (cited earlier in the thread):
http://msdn.microsoft.com/en-us/library/ms811450.aspx
"In OLE DB, a service is implemented as a controlling object that
aggregates the native object exposed by the data store. When the
application requests an interface that represents some set of
functionality natively supported by the data store, the service returns
the data store's native interface and the application interacts with the
data store directly. When the application requests some set of
functionality not supported by a native interface on the data store, the
service can provide a standard implementation of that functionality,
interacting with the data store through the same native interfaces
exposed to the application. In this manner, the application always gets
the most direct, efficient path to the data. Whether the functionality
is implemented natively by the data store or through an external service
is completely transparent to the application."
It looks like Microsoft thought that their "Recordset Automation"
interface would not slow down things much, especially for methods that
already exist in the native technology. At least that's the way it
appeared to me when I read it.
And once you're using ODBC to work with server data, you might as
well use DAO.
O.K.
Explanations of his theory about ADO's deprecation (the word
'failure' doesn't seem quite right but YMMV) can be found here:
http://groups.google.com/group/comp.databases.ms-access/msg/7bb73e0
7f2220433
http://groups.google.com/group/comp.databases.ms-access/msg/6240845
fa7598fe0
[Google Groups now requires a logon! Well, if I didn't already have
one, I think I'd quit using it]
Both those articles seem to me to be about deprecation of ADPs, not
ADO. While the abandonment of ADPs certainly removes one of the few
contexts in which ADO shines, that isn't the same thing as direct
deprecation of ADO. I'm not sure that MS really officially
deprecates ADO for use with Access. I think they de facto downplay
One of the literal meanings of "deprecate" is to deemphasize or downplay
something so I suppose it depends on how official the deprecation becomes.
it, especially in comparison to the halcyon days after the
introduction of Access 2000, whenever everybody in the Access groups
was posting in the newsgroups saying how they were planning to learn
ADO because it was obviously the next great thing from MS and the
wave of the future, blah blah blah.
Nobody was happy with the way Microsoft tried to ply all this on
everyone. Bits and pieces make sense, but it seems that Microsoft for
some reason doesn't want us to know the full story. For the last
several years Microsoft has been reacting to other technology threats,
sometimes poorly, but I am still not satisfied with the explanations of
what happened. Besides, Access is still COM based. Wouldn't it have
been possible for Microsoft to keep up progress with ADODB in Access
until it eventually got XML based and shed COM? Do they need the entire
Access team to work on XSLT to get that right?
Working with SQL Server, it has a number of marvelously useful
features. Otherwise, not so much.
I agree. DAO for Access/Jet backends and ADODB for SQL backends seems
to be the mantra unless your circumstances are special. Of course, I
have a distaste for mantras in general (without taking this sentence as
a mantra).
James A. Fortune
(e-mail address removed)
