L
Lyle Fairfield
Take another look at what I wrote.
I have. It seems that what I read was not what you wrote. Thank you
for clarifying.
Take another look at what I wrote.
Oops, missed this earlier!
That's a valid point against ADO if you are only interested in
performance. Now think about data integrity: some database
constraints (including primary keys) cannot be implemented with
indexes and Validation Rules alone (big hint: table-level CHECK
constraints). But that that's just two issues out of many so let's
not do the ADO vs DAO thing again here and instead focus on the
question in hand i.e. should one avoid a feature (ADP) merely
because 'Micosoft support' no longer recommends it?
Doesn't the existence of ADO 6.0 for (as you say) backward
compatibility prove MSFT's commitment to fixing ADO
"problems under Vista"? Otherwise, they would have just
shipped MDAC 2.8, surely?
ADO
can still be used (I am not, however, certain about Classic
ADO and the new ACCDB database format),
so it has not
officially been "deprecated". It's just not something you want
to bet your future on.
It's not DAO or ADO that is deficient or dying. They're both great in
Microsoft land. But the rain isn't falling on Microsoft land much any
more. And the soil is drying up. And there are skeletons on the
plains. No one is noticing. But someday soon we will look at the old
vista we remember, and it won't be the same.
I posted about this some months ago. There is a new
ACE provider and ADO works just fine with Access
2007 and its various associated technologies.
I think that if that's the case then you and the other MVPs
who believe as you do should encourage Micorsoft to
take down this page where it says:
ADO will continue to be ENHANCED
Jet is DEPRECATED and
DAO is OBSOLETE,
onedaywhen said:That's a valid point against ADO if you are only interested in
performance. Now think about data integrity: some database constraints
(including primary keys) cannot be implemented with indexes and
Validation Rules alone (big hint: table-level CHECK constraints). But
that that's just two issues out of many so let's not do the ADO vs DAO
thing again here and instead focus on the question in hand i.e. should
one avoid a feature (ADP) merely because 'Micosoft support' no longer
recommends it?
"Classic ADO" ... has been superceded in
the Microsoft world by ADO.NET
Out of consideration for those who adopted classic ADO and used it,
Microsoft has kept it around* and, presumably, if defects are found, they
will consider the business case for fixing them (always a trade-off, in the
corporate world -- a defect, no matter how long-standing, that affects only
a few users will be near the bottom of the priority list for investigation
and correction). But, it is not a technology in which Microsoft can be
expected to make investments "going forward".
You can still create a new
Access Project (ADP), still maintain existing ones, and ADO
can still be used (I am not, however, certain about Classic
ADO and the new ACCDB database format)
[ADP is] just not something you want to bet your future on.
has made a comeback seemingly against MSFT's game plan so will ADPFrom the 'outside' it's hard to see how things will play out e.g. DAO
Micorsoft to take down this page
where it says:
ADO will continue to be ENHANCED
Jet is DEPRECATED
and
DAO is OBSOLETE,
http://msdn2.microsoft.com/en-us/library/ms810810.aspx
entitled Data Access Technologies Road Map
According to that quote of which you were so proud, this ADO
6.0 is "functionally identical" to the previous version, which suggests to
me that it's only purpose is to provide backward compatibility. Presumably
there were technical reasons why the previous version wouldn't work under
Vista (or, it is in fact exactly the same thing and they just renamed it).
I fail to understand why you are so keen to prove that ADO has a future.
The Jet db engine doesn't support the features you are talking
about.
And they aren't really relevant to a data interface language
like ADO, anyway. Setting them up and modifying them is a matter of
DDL for the relevant database engine, and I doubt that Jet or ADO
mucks around with DDL statements before handing them off to a
server.
Microsoft purposely muddied the waters by intentionally not updating
DAO 3.6 to support new features in Jet 4, and added support for a
handful of Jet features only in ADO.
Agreed.
I hope that with A2K7 and a new
commitment to DAO and Jet, that MS has done the right thing and
implemented direct support for all of the features of the db engine.
onedaywhen said:From the 'outside' it's hard to see how things will
play out e.g. DAO has made a comeback seemingly
against MSFT's game plan so will ADP survive in
coming years with enough support to make it viable?
David has used ADO not at all, or very little.
He has not studied it.
He has neither the skills nor the experience to implement it, yet
he constantly denigrates it and expresses absolute opinions about
it.
David is not alone. He is joined by MVPs and other experienced
Access developers. I often wonder why. Is it because they are
inherently conservative and do not trust this new (what 1998?)
technology?
Is it
because they have a cozy business based upon Access and DAO?
Is it
because they do not have the intellectual capacity to keep several
technologies active in their brains at the same time? I don't
know.
I
don't care. I can and have used DAO and ADO extensively. I have
forgotten more about DAO than many of its champions know; I have
used ADO more extensively than most. Each is a fine technology.
I like ADO;
it has a broad list of capabilities and it has a broad list of
situations in which it can be used.
The notion that it is dead is
absurd.
But when it's advantageous to use DAO, I use DAO.
What I do
care about and think that this newsgroup avoids is not the future
of ADO, nor of DAO. It is the future of Microsoft. Ten years ago
Microsoft did everything better; it was vibrant and it was
developing technologies which were needed and wanted. Today it is
developing redundant technologies to hawk.
I have learned all about .Net except
for one tiny thing: where I would want to use it.
Oh I know, it's
Superior! And it may be for some. But I have not found that it is
superior for an experienced programmer/developer. And no, I don't
like apps which can do in ten thousand lines what I used to do in
eight (no, not eight thousand lines, eight lines).
The computer on which I am writing has Windows and its associated
technologies such as Internet Explorer installed. But it is fully
provisioned with other [FREE] software that is not Microsoft. How
much am I missing Microsoft? Not at all? What have I been unable
to do that I could do with Microsoft ? Not a thing. How many
crashes/ failures have I had with this new software during
February? None. How often and big are the updates? I don't know
because invariably the updates are so simple and swift that I
forget that they happened. I re-installed Windows XP from the
original OEM cds last week and was hit by a total of 113 updates.
One hundred and thirteen! Next I turned on a new Vista computer.
Ah, I thought, they'll be sure to have this very annoying updating
cured. WRONG! Seven updates were required. After three weeks there
were SEVEN F___KING updates required. SEVEN F___KING updates
required after three weeks of availability.
(Sorry, it seems I have repeated myself) Is this
Microsoft company a JOKE or what?
It's not DAO or ADO that is deficient or dying. They're both great
in Microsoft land. But the rain isn't falling on Microsoft land
much any more. And the soil is drying up. And there are skeletons
on the plains. No one is noticing. But someday soon we will look
at the old vista we remember, and it won't be the same.
In the MDB world, I note that the Control
Wizards no longer generate VBA in Access 2007, but generate (the
improved?) macros, instead, and that, I take as some confirmation
of my view of their revised emphasis.
David W. Fenton said:But there was actually a reasonable justification for
this: macros can be executed safely (because of the
limited set of available commands) and VBA code can't.
Frankly, I've been a developer since before Bill Gates was in Junior
High School, when he was borrowing time on somebody's minicomputer to
learn programming, and much before he founded Microsoft. For me, it's
a little late to have an interest in switching to "user software
support" -- that's for the interns that the company hires from local
colleges to support technical education and scope out promising young
new hires.
The "poor old fellow" has been taken in to the Access
assisted-living facility and is being nursed along with occasional doses of
Software Growth Hormone (e.g., the support for ACCDB)
It didn't take a genius to understand that the recommendation by MS
to use ADO with Jet data was a mistake.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.