Microsoft ADO Ext. 2.8 for DDL and Security | Where did it go?

[David W. Fenton]

Hmmm... If ADO was supposed to be like a superset of DAO

No, that's not even close.

ADO was a replacement for ODBC, i.e., a back-end-agnostic interface
to all databases.

that included
other technologies (and supposedly no loss in speed when using DAO
- har!), then why wasn't it designed so that the DAO part of ADO
would work exactly the same as DAO?

The major premise of your question is in error, so the followon from
it is by definition wrong.

My point is that it's only a stupid
decision in hindsight.

No, it was clearly a bloody stupid decision to deprecate the native
data interface for Jet in favor of a generic data interface layer
for use with Jet. That was clear to me (and a whole host of others)
at the time Access 2000 was released.

The goal of ADO was a good one.

Yes, it was, if you define the goal as having ADO be a modern
replacement for ODBC.

But using a replacement for ODBC to work with Jet data when you're
running Access (which uses Jet files to store its application
objects), just makes no sense whatsoever. And it never did. And
many, many people knew that.

And it didn't even succeed as a replacement for ODBC, since it was
soon abandoned in favor of ADO.NET, which has very little in common
with classic ADO.

Had they
accomplished DAO speed with JET (one of their stated goals)

I don't know that this was one of their stated goals. Can you
provide documentation for that?

In any event, using a non-native generic database abstraction layer
can *never* be as fast as the native interface to a particular
database engine, so I strongly doubt that was ever their goal.

along with
the universality and security they hoped to accomplish,

What does security have to do with ADO? Security is provided by the
database engine, not by the interface layer.

we'd all be
doing everything in ADO.

If pigs had wings, we wouldn't be complaining about pigeon
droppings.

Now that DAO is back,

DAO never went away for those working with Jet data. Microsoft's
corporate agenda tried to deprecate it in favor of ADO, but that
didn't last long (two versions of Access, or maybe even only one).

you are correct that it
should be retrofitted with some of the ADO capabilities.

No, not ADO capabilities. The DAO interface should be updated to
reflect all the capabilities of the Jet database engine.

Maybe
a single connection object is not capable of handling all the
necessary methods for both data objects simultaneously.

Eh? What? This has zilch to do with the problems of ADO, except of
course, that the whole concept of the connection object is pretty
much a server database type of concept, and not really appropriate
for Jet.

 

[James A. Fortune]

David,

My comments were based mostly on the following article:

OLE DB/ADO: Making Universal Data Access a Reality

http://msdn.microsoft.com/en-us/library/ms811450.aspx

The comments about security were related to Lyle's comments in CDMA
about the creation of new connections and the use of application roles
to limit data access by users.

I agree with most of your comments, but I think you don't have the whole
story.

James A. Fortune
(e-mail address removed)

 

[Larry Linson]

Jim, OLE DB and ADO were just two in a long string of "bright ideas" that
Microsoft's development folks had regarding "better user experience" for
accessing data. Like the vast majority of the ideas in that "long string",
they didn't turn out to be as wonderful as someone had hoped. ADO.NET seems
to have lasted longer in the world of DotNet than any of those did, but
given the history, it would not surprise me in the least to see it
supplanted by "yet another latest and greatest data access approach that is
going to 'save the world'".

I mentally smiled whenever I saw a new "flavor of the release" data access
approach announced with a new classic VB release -- it reminded me of my
mainframe days when we got so many new Computer Science grads who arrived,
out in the trenches, expecting to be allowed to write "The Compiler That
Saved The World". Somehow, the CS programs of the day had used compilers as
examples so much that the grads were convinced that the world was in need of
saving, that a sufficiently great compiler was what was going to save it,
and that, having excelled for 4 years in a CS program, they were the one who
was going to create that new and superb compiler. Most of them did get over
the shock of discovering that the people who wrote compilers were few, that
they lived back in the development division, and included practically no
inexperienced new grads, no matter how well they had performed in their
studies. Some of those turned out to have sufficient understanding to create
software that was useful in running customers' organizations, business,
education, or government.

Larry

 

[James A. Fortune]

Jim, OLE DB and ADO were just two in a long string of "bright ideas" that
Microsoft's development folks had regarding "better user experience" for
accessing data. Like the vast majority of the ideas in that "long string",
they didn't turn out to be as wonderful as someone had hoped. ADO.NET seems
to have lasted longer in the world of DotNet than any of those did, but
given the history, it would not surprise me in the least to see it
supplanted by "yet another latest and greatest data access approach that is
going to 'save the world'".

I mentally smiled whenever I saw a new "flavor of the release" data access
approach announced with a new classic VB release -- it reminded me of my
mainframe days when we got so many new Computer Science grads who arrived,
out in the trenches, expecting to be allowed to write "The Compiler That
Saved The World". Somehow, the CS programs of the day had used compilers as
examples so much that the grads were convinced that the world was in need of
saving, that a sufficiently great compiler was what was going to save it,
and that, having excelled for 4 years in a CS program, they were the one who
was going to create that new and superb compiler. Most of them did get over
the shock of discovering that the people who wrote compilers were few, that
they lived back in the development division, and included practically no
inexperienced new grads, no matter how well they had performed in their
studies. Some of those turned out to have sufficient understanding to create
software that was useful in running customers' organizations, business,
education, or government.

Larry

I have a long history of Microsoft bashing -- and they deserved it,
but, using your analogy, it doesn't mean that the idea of creating a
"compiler that is going to save the world" was a bad idea, per se. I
don't think that it was as simple as David's "native technology just
works better." Microsoft didn't make it clear exactly what problems ADO
had that caused its relegation to the list of bright ideas gone sour.
It's possible that someone at Microsoft, with a little thought, could
have seen in advance that ADO contained some kind of show stopper. Just
because ADO had some kind of problem is not going to make me slap my
forehead and say, "Duh, JET, of course, I should have known all along!"

James A. Fortune
(e-mail address removed)

 

[David W. Fenton]

My comments were based mostly on the following article:

OLE DB/ADO: Making Universal Data Access a Reality

http://msdn.microsoft.com/en-us/library/ms811450.aspx

That article is TEN YEARS OLD. It is completely out of date, and it
even predates the introduction of Access 2000, the first Access
version to include ADO as the *default* data interface layer.

And how you got "ADO was a replacement for DAO" out of that, I can't
say, given that DAO is by definition a provider-specific data
interface layer, while the article right at the top says:

ActiveX® Data Objects (ADO) [is] a provider-neutral,
application-level data access object model

PROVIDER-NEUTRAL. In other words, it's a replacement for ODBC.

DAO isn't even mentioned in that article.

And, of course, ADO/OLEDB is COM-based, and .NET makes COM obsolete
(which is why there is now ADO.NET, which has virtually nothing in
common with classic COM-based ADO).

The comments about security were related to Lyle's comments in
CDMA about the creation of new connections and the use of
application roles to limit data access by users.

Er, application roles indicates SQL Server as back end. That is,
security is handled by the back end, not by the data interface
layer.

I agree with most of your comments, but I think you don't have the
whole story.

I think you are completely wrong in regards to everything you've
written in this thread.

 

[David W. Fenton]

I have a long history of Microsoft bashing -- and they
deserved it, but, using your analogy, it doesn't mean that the
idea of creating a "compiler that is going to save the world" was
a bad idea, per se. I don't think that it was as simple as
David's "native technology just works better."

You're leaving out a crucial clause of my argumetn:

Native technology works better for the native back end.

There is not doubt whatsoever that DAO is a superior interface to
ADO.

The only reason ADO is competitive at all is because of Microsoft's
artificial decision to support some Jet 4 functions in ADO and not
support them in DAO. This gives ADO artificial advantage in terms of
features that there is no logcial reason for it to have.

Microsoft didn't make it clear exactly what problems ADO
had that caused its relegation to the list of bright ideas gone
sour.

It was clear from the beginning why it was inferior to DAO for Jet
data.

Unless you were not very smart and just swallowed the MS Kool Aid.

It's possible that someone at Microsoft, with a little thought,
could have seen in advance that ADO contained some kind of show
stopper. Just because ADO had some kind of problem is not going
to make me slap my forehead and say, "Duh, JET, of course, I
should have known all along!"

ADO as replacement for ODBC was a great idea. ADO from an ADP to SQL
Server is quite useful. But MS has abandoned ADO, and all the cool
ideas for a universal data interface have been put into ADO.NET,
which we can't use in Access.

Again, the argument here is not over DAO with ODBC/[non-Jet db
engine] vs. ADO with the same db engine, but over DAO with Jet vs.
ADO with Jet.

It is simply no contest.

And it never was.

 

[david]

PROVIDER-NEUTRAL. In other words, it's a replacement for ODBC.

I don't think I agree with you on this.

Access (called Access) was a provider neutral technology.
DAO (Data Access) was a provider neutral technology.

A standard interface provided by MS to all kinds of technology, from Oracle
to Excel. No standard interface required or expected on the provider side:
MS did it all.

ODBC was not a provider neutral technology: It required
that all ODBC data sources implement a SQL Engine, and
it defined a standard SQL interface.

A stated purpose of ADO was to be provider neutral, providing
a standard COM interface on both sides, not requiring a SQL
engine in the data provider.

When you look at the boasted feature list of ADO, when you
look at what was so great about ADO, when you look at why
ADO was better than 'previous' technologies, you see that it
is doing what DAO always did.

The difference was that Jet had a private (windows dll) api to
the Installable ISAMs, which was never documented, and ADO
had a documented COM interface to the installable engines.

And then COM was discarded and replaced with NET.

(david)

My comments were based mostly on the following article:

OLE DB/ADO: Making Universal Data Access a Reality

http://msdn.microsoft.com/en-us/library/ms811450.aspx

That article is TEN YEARS OLD. It is completely out of date, and it
even predates the introduction of Access 2000, the first Access
version to include ADO as the *default* data interface layer.

And how you got "ADO was a replacement for DAO" out of that, I can't
say, given that DAO is by definition a provider-specific data
interface layer, while the article right at the top says:

ActiveX® Data Objects (ADO) [is] a provider-neutral,
application-level data access object model

PROVIDER-NEUTRAL. In other words, it's a replacement for ODBC.

DAO isn't even mentioned in that article.

And, of course, ADO/OLEDB is COM-based, and .NET makes COM obsolete
(which is why there is now ADO.NET, which has virtually nothing in
common with classic COM-based ADO).

The comments about security were related to Lyle's comments in
CDMA about the creation of new connections and the use of
application roles to limit data access by users.

Er, application roles indicates SQL Server as back end. That is,
security is handled by the back end, not by the data interface
layer.

I agree with most of your comments, but I think you don't have the
whole story.

I think you are completely wrong in regards to everything you've
written in this thread.

 

[James A. Fortune]

That article is TEN YEARS OLD. It is completely out of date, and it
even predates the introduction of Access 2000, the first Access
version to include ADO as the *default* data interface layer.

It also predates any revisionist history . Its age is its strength.
Microsoft will probably remove it soon.

And how you got "ADO was a replacement for DAO" out of that, I can't
say, given that DAO is by definition a provider-specific data
interface layer, while the article right at the top says:

ActiveX® Data Objects (ADO) [is] a provider-neutral,
application-level data access object model

PROVIDER-NEUTRAL. In other words, it's a replacement for ODBC.

DAO isn't even mentioned in that article.

They may have removed the other article I read by now. Perhaps the
attempt to deprecate DAO proves the point just as well. The (old)
article above makes it clear that ADO/OLEDB was an attempt to roll up
several technologies into one.

And, of course, ADO/OLEDB is COM-based, and .NET makes COM obsolete
(which is why there is now ADO.NET, which has virtually nothing in
common with classic COM-based ADO).

I doubt that pushing .NET had anything to do with the weaknesses of
ADO/OLEDB. It may explain some other things.

Er, application roles indicates SQL Server as back end. That is,
security is handled by the back end, not by the data interface
layer.

It still relates to a possibly fatal weakness, one that Lyle thought was
the main reason for MS backing off on OLEDB/ADO.

I think you are completely wrong in regards to everything you've
written in this thread.

No one doubts that DAO is the fastest technology for JET. The question
is, "How close to native speed does a roll up technology have to be for
its benefits to outweigh the native technology?" I don't think you're
even close when you cite native JET speed superiority as the Achilles'
heel of OLEDB/ADO.

James A. Fortune
(e-mail address removed)

 

[Dominic Vella]

My gripe was simply that "Microsoft change their ideas without helping the
developers" that support their product. When ADO was introduced, I felt
there was adequate documentation on the change over, but now there seems to
be none. I didn't know they abandoned ADO, they don't provide any
contingincies. Other matters that stung was:
* date picker that pushes it's way over the top of my own date button.
Great for 2007 but cruel for businesses with multiple platforms.
* packaging and deployment gets shut down if you get updates, instead of
improved. Microsoft are happy to shut your development work down if your
clients are slow to upgrade.
* FindWindow, GetData works on some VISTA machines, not others. Why is it
so? What are they? Where was microsofts vision in them?

It get's to the stage where I fear upgrading or updating, scared what parts
of my software will they shut down next. They don't care about the
developers. They seem only to care that the world is forced to purchase new
Microsoft products by purposefully destroying the old.

Instead of causing the world to grit their teeth everytime they mention
'Microsoft', wouldn't it be nicer if they helped Office developers
transition with some support. As for the articles they publish, well I
find Allen Browne's website much more useful. Microsoft doesn't admit they
have bugs, and don't care if the bugs exist. They dont want to help you,
they just want you to upgrade.

Don't tell me there's nothing wrong, look at the size of this thread, it's
rediculous considering the simple nature of the first note, and this just
only about ADOX, one issue of many.

Dom

That article is TEN YEARS OLD. It is completely out of date, and it
even predates the introduction of Access 2000, the first Access
version to include ADO as the *default* data interface layer.

It also predates any revisionist history . Its age is its strength.
Microsoft will probably remove it soon.

And how you got "ADO was a replacement for DAO" out of that, I can't
say, given that DAO is by definition a provider-specific data
interface layer, while the article right at the top says: ActiveX® Data
Objects (ADO) [is] a provider-neutral,
application-level data access object model PROVIDER-NEUTRAL. In other
words, it's a replacement for ODBC.

DAO isn't even mentioned in that article.

They may have removed the other article I read by now. Perhaps the
attempt to deprecate DAO proves the point just as well. The (old) article
above makes it clear that ADO/OLEDB was an attempt to roll up several
technologies into one.

And, of course, ADO/OLEDB is COM-based, and .NET makes COM obsolete
(which is why there is now ADO.NET, which has virtually nothing in
common with classic COM-based ADO).

I doubt that pushing .NET had anything to do with the weaknesses of
ADO/OLEDB. It may explain some other things.

Er, application roles indicates SQL Server as back end. That is,
security is handled by the back end, not by the data interface
layer.

It still relates to a possibly fatal weakness, one that Lyle thought was
the main reason for MS backing off on OLEDB/ADO.

I think you are completely wrong in regards to everything you've
written in this thread.

No one doubts that DAO is the fastest technology for JET. The question
is, "How close to native speed does a roll up technology have to be for
its benefits to outweigh the native technology?" I don't think you're
even close when you cite native JET speed superiority as the Achilles'
heel of OLEDB/ADO.

James A. Fortune
(e-mail address removed)

 

[David W. Fenton]

I don't think I agree with you on this.

Access (called Access) was a provider neutral technology.

Eh? What the frack are you talking about? You're mixing in concepts
that just make complete hash of any logical discussion.

DAO (Data Access) was a provider neutral technology.

No, it's not. DAO REQUIRES Jet. It is an interface entirely designed
for the purpose of controlling Jet. Jet, on the other hand, has a
lot of capabilities that allow it to work with many different back
end databases (via ODBC).

A standard interface provided by MS to all kinds of technology,
from Oracle to Excel. No standard interface required or expected
on the provider side: MS did it all.

Eh? What the hell are you talking about?

ODBC was not a provider neutral technology: It required
that all ODBC data sources implement a SQL Engine, and
it defined a standard SQL interface.

Yes. Provider-neutral. As long as there's an ODBC driver.

A stated purpose of ADO was to be provider neutral, providing
a standard COM interface on both sides, not requiring a SQL
engine in the data provider.

Yes. It was intended as an improvement on ODBC.

When you look at the boasted feature list of ADO, when you
look at what was so great about ADO, when you look at why
ADO was better than 'previous' technologies, you see that it
is doing what DAO always did.

But DAO provided access to non-Jet data sources only through ODBC
(and, I guess, ISAMs).

The difference was that Jet had a private (windows dll) api to
the Installable ISAMs, which was never documented, and ADO
had a documented COM interface to the installable engines.

And this is relevant exactly how?

And then COM was discarded and replaced with NET.

This is true, and that's why ADO is pretty limited as to what it's
useful for these days.

....

You don't seem to be able to maintain any kind of coherent thread of
argument, so you're hitting my killfile:

<PLONK>

 

[David W. Fenton]

No one doubts that DAO is the fastest technology for JET.

Then what the hell are you arguing with me for -- that's the ONLY
claim I've ever made in this thread in regard to speed.

The question
is, "How close to native speed does a roll up technology have to
be for its benefits to outweigh the native technology?" I don't
think you're even close when you cite native JET speed superiority
as the Achilles' heel of OLEDB/ADO.

Where, exactly, did I cite any such thing?

I DID NOT.

Get a grip.

 

[David W. Fenton]

* FindWindow, GetData works on some VISTA machines, not others.
Why is it so? What are they? Where was microsofts vision in them?

This is likely due to differing security contexts on the different
machines. Microsoft bit the bullet with Vista and has finally gotten
around to forcing developers to write their apps so that they don't
require elevated privileges. Too bad that MS was pushed into this
position by the stupid application developers out there who have
ignored this issue for the last 10 years (Intuit's QuickBooks is the
prime example of this).

It get's to the stage where I fear upgrading or updating, scared
what parts of my software will they shut down next. They don't
care about the developers. They seem only to care that the world
is forced to purchase new Microsoft products by purposefully
destroying the old.

This is the reaction many of us Access developers had to the release
of Access 2000, which made clear that MS was sacrificing Access's
best interests to its corporate agenda.

Welcome to the real world.

 

[James A. Fortune]

The question is mine. It was meant to demonstrate that a slight speed
loss due to the interface would not have been enough of a reason to
deprecate OLEDB/ADO.

Where, exactly, did I cite any such thing?

I DID NOT.

Get a grip.

Earlier in this thread you said:

<Quote>
Yes, and that turned out to be an incredibly stupid decision on MS's
part, since now DAO is no longer deprecated -- it's now the
preferred interface for interacting with Jet data (as it *should*
have been all along).

Adding new features breaks things. Particularly, as with Access,
when the new features aren't tested properly, and don't fit with
the original underlying architecture.

Eh? This is an interface to a feature in the Jet database engine.
Where you put programmatic control of that has *nothing* to do with
the actual underlying architecture -- it's just an interface.

So DAO was walled off as deprecated, and they tried not to
break it. I think that was a reasonable approach.

It was a bloody stupid decision and most people who understood what
DAO was realized it was stupid and continued to use DAO for
interacting with Jet data.

ADO is now the dead interface, and the Jet features for which a
programmatic interface is provided in ADO should have those
programmatic interfaces implemented in DAO, which is again (as it
should have been all along) the preferred interface for interacting
with Jet data.
</Quote>

Perhaps I misunderstood your point. What exactly did you think was the
reason DAO is now preferred to ADO?

James A. Fortune
(e-mail address removed)

 

[Dominic Vella]

Wow, what a sore point

Dom

 

[James A. Fortune]

They may have removed the other article I read by now. Perhaps the
attempt to deprecate DAO proves the point just as well. The (old)
article above makes it clear that ADO/OLEDB was an attempt to roll up
several technologies into one.

Here is some more information I discovered while searching for the
sources of some of my comments:

From:

(Creating Programmable Database Applications with Access 97, 2000, 2002
& 2003)
Access Database Design and Programming, Third Edition 2002
Steven Roman
ISBN: 0-596-00273-4

p. 269

In this chapter, we will discuss Microsoft's latest database programming
object model, called ActiveX Data Objects, or ADO. This object model is
a successor to DAO and is intended to replace DAO.

p. 272

On the other hand, ADO has a more ambitious goal--it is the programming
model for a universal data-access interface called OLE DB. Simply put,
OLD DB is a technology that is intended to be used to connect to any
type of data--traditional database data, spreadsheet data, web-based
data, text data, email data, and so on.

Technically speaking, OLD DB is a set of COM interfaces. An interface
is just a collection of functions, also called services, with a similar
purpose. The term COM refers to the Component Object Model, which is
Microsoft's model for communication between software components. Thus,
simply put, OLE DB is a set of functions or services.

p. 273

Here is a sampling of the OLE DB data providers available at the time of
this writing [2002]:

• Microsoft OLD DB Simple Provider (a JavaBeans-related interface)

• Microsoft OLD DB Provider for ODBC Drivers (for Open Database
Connectivity)

• Microsoft OLE DB Provider for Oracle (for Oracle databases)

• Microsoft Jet 3.51 OLE DB Provider (for Jet databases)

• Microsoft OLE DB Provider for SQL Server (for SQL Server databases)

• Microsoft OLE DB Provider for Directory Services (provides directory
services--that is, logon, administration, and replication services--for
Windows NT Server networks)

p. 381

In this appendix, we take a close look at ODBC, which is a part of both
DAO and ADO and probably will be for some time to come, despite
Microsoft's desire to replace all previous database technologies with
OLE DB and ADO.

[Other interesting, but unrelated comments:]

p. 316

The procedure uses the SQL statement:

"SELECT * FROM [MasterTable$]"

to open a recordset based on this table. (I can't tell you how long it
took me to determine that a dollar sign must be appended to the end of
an Excel worksheet name.)

We set the connect string to:

' Connection string
cn.ConnectionString = _
"DRIVER={Microsoft Excel Driver
(*.xls)};DBQ=D:\BkAccessII\Connect.xls;"

Note the DBQ parameter. Based on the documentation from Microsoft that
I quoted earlier, I first tried to use the parameter name DATABASE, but
was rudely rewarded with the message "Operation cancelled" at the line:

cn.Open

(In case you are wondering how I discovered that DBQ was the correct
name, I used the ODBC Administrator to create a DSN and inspected the
DSN file with a text editor.)

p. 333

I wish Microsoft would continue to support DAO.

James A. Fortune
(e-mail address removed)

 

[david]

Here is some more information I discovered while searching for the sources
of some of my comments:

From:

(Creating Programmable Database Applications with Access 97, 2000, 2002 &
2003)
Access Database Design and Programming, Third Edition 2002
Steven Roman
ISBN: 0-596-00273-4

p. 269

In this chapter, we will discuss Microsoft's latest database programming
object model, called ActiveX Data Objects, or ADO. This object model is a
successor to DAO and is intended to replace DAO.

p. 272

On the other hand, ADO has a more ambitious goal--it is the programming
model for a universal data-access interface called OLE DB. Simply put,
OLD DB is a technology that is intended to be used to connect to any type
of data--traditional database data, spreadsheet data, web-based data, text
data, email data, and so on.

There's the intention to replace ODBC (a 'more ambitious goal')
with a DAO replacment - a universal data-access interface to any
type of data using .COM.

So the spreadsheet interface was then provided by the Jet engine:

"DRIVER={Microsoft Excel Driver
(*.xls)};DBQ=D:\BkAccessII\Connect.xls;"

-- all without really admitting to understanding what he was talking about.

(david)

 

[matte]

sat fak up

My comments were based mostly on the following article:

OLE DB/ADO: Making Universal Data Access a Reality

http://msdn.microsoft.com/en-us/library/ms811450.aspx

That article is TEN YEARS OLD. It is completely out of date, and it
even predates the introduction of Access 2000, the first Access
version to include ADO as the *default* data interface layer.

And how you got "ADO was a replacement for DAO" out of that, I can't
say, given that DAO is by definition a provider-specific data
interface layer, while the article right at the top says:

ActiveX® Data Objects (ADO) [is] a provider-neutral,
application-level data access object model

PROVIDER-NEUTRAL. In other words, it's a replacement for ODBC.

DAO isn't even mentioned in that article.

And, of course, ADO/OLEDB is COM-based, and .NET makes COM obsolete
(which is why there is now ADO.NET, which has virtually nothing in
common with classic COM-based ADO).

The comments about security were related to Lyle's comments in
CDMA about the creation of new connections and the use of
application roles to limit data access by users.

Er, application roles indicates SQL Server as back end. That is,
security is handled by the back end, not by the data interface
layer.

I agree with most of your comments, but I think you don't have the
whole story.

I think you are completely wrong in regards to everything you've
written in this thread.

 

[David W. Fenton]

Here is some more information I discovered while searching for the
sources of some of my comments:

From:

(Creating Programmable Database Applications with Access 97, 2000,
2002 & 2003)
Access Database Design and Programming, Third Edition 2002
Steven Roman
ISBN: 0-596-00273-4

Is that published by Microsoft? No, it's published by O'Reilly, who
cannot speak for Microsoft in regard to what ADO was intended to be.

p. 269

In this chapter, we will discuss Microsoft's latest database
programming object model, called ActiveX Data Objects, or ADO.
This object model is a successor to DAO and is intended to replace
DAO.

This information is simply mistaken. While MS certainly rolled out
ADO in Access with the intention that developers use it instead of
DAO, it was A DUMB THING FOR THEM TO DO, and that's why they
reversed their position.

p. 272

On the other hand, ADO has a more ambitious goal--it is the
programming model for a universal data-access interface called OLE
DB. Simply put, OLD DB is a technology that is intended to be
used to connect to any type of data--traditional database data,
spreadsheet data, web-based data, text data, email data, and so
on.

Technically speaking, OLD DB is a set of COM interfaces. An
interface is just a collection of functions, also called services,
with a similar purpose. The term COM refers to the Component
Object Model, which is Microsoft's model for communication between
software components. Thus, simply put, OLE DB is a set of
functions or services.

This contradicts the other quotation about DAO.

[]

p. 381

In this appendix, we take a close look at ODBC, which is a part of
both DAO and ADO and probably will be for some time to come,
despite Microsoft's desire to replace all previous database
technologies with OLE DB and ADO.

This book you're citing is *really* badly written. ODBC is *not* at
all part of either DAO or ADO -- but both DAO and ADO provide
interfaces to interact with ODBC providers.

 

[James A. Fortune]

Is that published by Microsoft? No, it's published by O'Reilly, who
cannot speak for Microsoft in regard to what ADO was intended to be.

O.K., that's a valid point. So what's your opinion on why ADO was
deprecated? I mean, the real reason. Lyle's theory makes sense but I'm
not sure it was the exact fly in the ointment that broke the camel's
back .

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/7bb73e07f2220433

http://groups.google.com/group/comp.databases.ms-access/msg/6240845fa7598fe0

Note that he is still a fan of ADO for many situations.

James A. Fortune
(e-mail address removed)

 

[James A. Fortune]

So the spreadsheet interface was then provided by the Jet engine:

Seems ironic, doesn't it?

-- all without really admitting to understanding what he was talking about.

James A. Fortune
(e-mail address removed)