William Vaughn said:
As cynical as this sounds, I'm with Stephen here. ADO.NET has (IMHO)
regressed in functionality in some respects from ADO classic. I would
embrace opening up the interface to see what it's doing so would could
get
around some of the "won't fix" or "can't fix" issues.
Yes I believe you can see a clear trail of the improvements.
I am somewhat timid in submitting a post in mild* favor of DAO, ADO, and
Microsoft's data access technologies in general. After all, Messrs. Howe
and
Vaughn, have likely forgotten more about data access that I ever knew. <g>
But I believe it is frequently overlooked that any data access library is
merely one layer in a stack of technologies. For example...
[ADO | DAO] <-> [OLE DB | ODBC] <-> ClientAPI <-> DatabaseEngine.
If one actually attempts to trace what goes on with even the simplest of
queries - it quickly becomes amazing that it works at all.
"They are all interfaces on the same set of database technology - which
does
not change." No, they are not. Database engines change, OLE
implementations
change. Microsoft has not only presented us with the programming data
access, they have also made amazing changes and improvements all down the
line and back again.
Also Microsoft (who was talking to IBM in those days <g>) was the primary
sponsor and the major reason ODBC was adopted. ODBC took us out of the
dark
ages of when every datasource, vendor, and language platform, had its own
access "libraries". I don't think MS gets nearly the credit it deserves.
Doesn't anyone remember the nightmare it used to be?
But sure ODBC had a flaw. It depended on everything to look like tables
with
a hierarchal structure. This made working with non-table datasource
difficult. So ADO came about. ADO's stated goal was Universal Access. And
it
accomplished that. We think nothing of using ADO to connect to anything.
"Give me a provider and I can move the world." <g>
But it is not my intention to provide a history lesson. Wikipedia can do
that.
Now to the question of why there are mysteries?
With ADO and SQLServer this seems strange - as Steve pointed out - "You
would think they would have it down pat by now". Especially when you
consider ADO and OLE DB and SQLServer were until recently the
responsibility
of the same team. But why, is basically because of three problems.
1) ADO is so prevalent that any fundlemental changes would require massive
regression testing.
2) the specter of the 1998 "United States vs.. Microsoft" civil suit.
While
it didn't happen MS came close to being broken up. As it is, they have to
be
very careful to share its application programming interfaces with
third-party companies, and not make any 'improvements' that effectively
break anything else, or perhaps even more important provide an obvious
advantage for themselves.
And 3) the shear complexity of the problem in the sense - what is optimal?
We all know there are more than one way in programming and no single
choice
is always the best choice.
Since the dawn of programming several things have always been paramount,
picking the best solution, you never knew until you tested it, and the
next
situation was likely different.
Yes ADO.Net has flaws, so did ADO, and so did DAO, and so did... But all
of
them had their strengths as well. Contrary to popular belief - NONE was
ever
a 100% optimal replacement of the other.
Which is why I always laugh when someone comes out says things like - "ADO
is the only way to go." Even today DAO with the right engine and server
will
thrash ADO. (eg, Jet and DB2)
Anyway this is too long. My apologizes to everyone.
[*"mild", I wouldn't want anyone to think I'm a MS bigot. I'm still pretty
m
iffed over what they did to VB, and the clumsy half-a** PITA that is
Vista.
Plus IMHO, if they would listen to me and done things the way I would have
done it, they would be better off. After all everything goes smoother when
people just do things MY way. <g>]
-ralph
