Are there known issues with Vista and Acc2003

  • Thread starter Thread starter Tony Ciconte
  • Start date Start date
No, it is not.

think about the difference between a native technology and a
translation layer
Click to expand...

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?

Jamie.

--
 
When will you get it? ADO is dead. D-E-A-D DEAD. If DAO has problems in
Vista and/or Acc 2007, it is once again a supported MS product so there is
at least a chance that the problems will get fixed. What will happen if ADO
has problems under Vista? Nothing, absolutely nothing, not now, not ever.
Why? Because it's DEAD.
Click to expand...

This is completely untrue.
 
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?

Jamie.

--
Click to expand...

ROFL!
 
When will you get it? ADO is dead. D-E-A-D DEAD.
If DAO has problems in
Vista and/or Acc 2007, it is once again a supported MS product so there is
at least a chance that the problems will get fixed.
Click to expand...

Well, another point in the somewhat tiresome 'ADO vs DAO' debate is
there remain ADO functionality (e.g. fetching records asynchronously)
absent from DAO and there remain areas of Jet functionality
inaccessible with DAO (see http://msdn2.microsoft.com/en-us/library/aa164825(office.10).aspx).
It seems reasonable to me to continue to use ADO for such things until
DAO has caught up with ADO.
What will happen if ADO
has problems under Vista? Nothing, absolutely nothing, not now, not ever.
Why? Because it's DEAD.
Click to expand...

You're sure about that, are you? See:

ADO History
http://msdn2.microsoft.com/en-us/library/ms676506.aspx

"ADO 6.0 is included in Windows Vista, as a part of the Windows Data
Access Components (Windows DAC) 6.0. ADO 6.0 is functionally
equivalent to ADO 2.8."

Jamie.

--
 
No, it is not.

HTH.

(think about the difference between a native technology and a
translation layer)
Click to expand...

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.

Now I'm cutting this and pasting it into Word or SWrite (Open Office)
to check spelling and grammar. Can you tell which I used?
 
David [W. Fenton] 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?
Click to expand...

I don't think that's correct. JRO is an ADO component (see
http://msdn2.microsoft.com/en-us/library/aa189021.aspx) and David
knows more about JRO than most, including me and I'm an ADO advocate.
ADO isn't so different from DAO and undoubtedly David processes the
required skills, so it's not that either. Rather, I think David just
hasn't *really* tried ADODB and he does not possess the normal 'don't
knock it until you've tried it' mentality (for better or worse).

Generally speaking, I think Access MVPs and other Access 'power users'
have really tried it and most do use it when appropriate, or at least
are prepared to post it in these groups. However, for the vast
majority of functionality it makes little difference whether you use
DAO and ADO. I like to say it's a 'lifestyle' choice and I think you
shouldn't go around trying to make people feel bad about 'lifestyle'
choices they've made; again, most MVPs seem to align with this (David
may not). Then again, I don't think anyone should be calling people
"idiot" (personal abuse being against the rules of these groups) but
wouldn't it be a dull place if everyone though and spoke like me <g>?

One of the most convincing arguments in favour of DAO is there are
more DAO code samples available than ADO, because it has been around
longer (is it *ever* justified to convert existing DAO code to
functionally-equivalent ADO or vice versa?) I get the feeling Access
MVPs generally prefer DAO because they have generally been around
longer. And it's self-perpetuating e.g. want to be an MVP (or seeking
re-election)? then act like an MVP and use DAO. Anyone remember VHS vs
Betamax? Technical superiority Best does not always secure the popular
vote.

Jamie.

--
 
Try calling MS support now. They recommend DAO with jet.
Click to expand...

My point!
50K lines of code is easy to come up with. Do you know what a
computerized maintenance mangement system is that controls work
assignment, inventory, purchasing, maintenance and PM schedules,
workers' hours, contractors, equipment, asset, building, room, vehicle
and hundreds of other lists of things facilities managers look after?
50K is nothing.

Some of us write and maintain very large applications.
Click to expand...

Boasting aside, what does line count tell us? I could take 10K lines
of dense 'Sub Main' style VBA code and make it OOP (build an object
model using a parent class plus child classes including collections
classes), add code comments and white space, make long lines of code
into several smaller ones (e.g. using continuation lines), etc and end
up with a line count of 50K that are functionally equivalent and
easier to read and maintain. I could take 50K lines of 'dynamic SQL'
style VBA code and create views and procs in the database and use a
data access component with a 'flat' object model (say, ADODB) to
invoke those views and procs with parameters and end up with a line
count of 10K that are functionally equivalent and easier to read and
maintain. So which is best: 50K or 10K? apples or oranges?

Jamie.

--
 
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?
Click to expand...

Merely? How about the tons of things that suck about them? Most Access
developers saw the folly of ADPs even when MS was encouraging their use. To say
that they are not recommending them now "merely" because MS has stopped pushing
them is a bit of a stretch.

The attitude change from MS is simply a bit of validation to the arguments that
have been there all along.
 
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?
Click to expand...

Merely? How about the tons of things that suck about them? Most Access
developers saw the folly of ADPs even when MS was encouraging their use. To say
that they are not recommending them now "merely" because MS has stopped pushing
them is a bit of a stretch.

The attitude change from MS is simply a bit of validation to the arguments that
have been there all along.
 
I don't think that's correct. JRO is an ADO component (seehttp://msdn2.microsoft.com/en-us/library/aa189021.aspx) and David
knows more about JRO than most, including me and I'm an ADO advocate.
Click to expand...

So David is an ADO user and advocate? Wonderful! I'm so pleased.

But I'm puzzled why one week ago he posted:

"I wouldn't use ADO at all. Ever."
 
onedaywhen said:
"ADO 6.0 is included in Windows Vista, as a part of the Windows Data
Access Components (Windows DAC) 6.0. ADO 6.0 is functionally
equivalent to ADO 2.8."

Jamie.
Click to expand...

I'm sure Vista contains lots of stuff for backward compatibility that MS has
no intention of further developing.
 
I'm sure Vista contains lots of stuff for backward compatibility that MS has
no intention of further developing.
Click to expand...

I'm don't despute *that*. But you originally asked, "What will happen
if ADO has problems under Vista?" and I think the answer is likely,
"MSFT will fix it in ADO 6.0".

Jamie.

--
 
onedaywhen said:
I'm don't despute *that*. But you originally asked, "What will happen
if ADO has problems under Vista?" and I think the answer is likely,
"MSFT will fix it in ADO 6.0".

Jamie.
Click to expand...

That I doubt.
 
That I doubt.
Click to expand...

Please explain why you think MSFT would create an ADO 6.0 especially
for Vista if they weren't going to fix "problems under Vista" in it?

Jamie.

--
 
onedaywhen said:
Please explain why you think MSFT would create an ADO 6.0 especially
for Vista if they weren't going to fix "problems under Vista" in it?

Jamie.

--
Click to expand...

Like I said, for backward compatibility. What makes you think they WILL fix
problems? They seem to find it hard enough to fix problems in products they
like, let alone products that they have clearly consigned to the bulging
dustbin labelled "seemed like a good idea at the time".
 
Like I said, for backward compatibility. What makes you think they WILL fix
problems?
Click to expand...

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?

Jamie.

--
 
onedaywhen said:
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?

Jamie.
Click to expand...

Not at all. 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.
You like it? Fine, it's still there, carry on using it. But, it's
blindingly obvious to me that Microsoft lost interest in it years ago, just
as it did ADP's, and probably regrets inventing both technologies and hence
adding to it's backward-compatibility headaches.
 
Back
Top