A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Are there known issues with Vista and Acc2003



 
 
Thread Tools Display Modes
  #11  
Old February 28th, 2007, 09:57 AM posted to comp.databases.ms-access,microsoft.public.access
onedaywhen
external usenet poster
 
Posts: 124
Default Are there known issues with Vista and Acc2003

On Feb 27, 11:20 pm, "David W. Fenton"
wrote:
you
took the "no longer recommended" path and stuck with DAO, even for
new projects. Isn't it reasonable for someone to take the same
approach now with ADP, ADO, etc?


No, it is not.

think about the difference between a native technology and a
translation layer


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.

--


  #12  
Old February 28th, 2007, 10:01 AM posted to comp.databases.ms-access,microsoft.public.access
onedaywhen
external usenet poster
 
Posts: 124
Default Are there known issues with Vista and Acc2003

On Feb 27, 11:20 pm, "David W. Fenton"
wrote:
you
took the "no longer recommended" path and stuck with DAO, even for
new projects. Isn't it reasonable for someone to take the same
approach now with ADP, ADO, etc?


No, it is not.

think about the difference between a native technology and a
translation layer


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.

--


  #13  
Old February 28th, 2007, 11:07 AM posted to comp.databases.ms-access,microsoft.public.access
Lyle Fairfield
external usenet poster
 
Posts: 36
Default Are there known issues with Vista and Acc2003

On Feb 28, 2:03 am, "Baz" wrote:
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.


This is completely untrue.

  #14  
Old February 28th, 2007, 11:09 AM posted to comp.databases.ms-access,microsoft.public.access
Lyle Fairfield
external usenet poster
 
Posts: 36
Default Are there known issues with Vista and Acc2003

On Feb 28, 4:01 am, "onedaywhen" wrote:
On Feb 27, 11:20 pm, "David W. Fenton"
wrote:

you
took the "no longer recommended" path and stuck with DAO, even for
new projects. Isn't it reasonable for someone to take the same
approach now with ADP, ADO, etc?


No, it is not.


think about the difference between a native technology and a
translation layer


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.

--


ROFL!

  #15  
Old February 28th, 2007, 11:51 AM posted to comp.databases.ms-access,microsoft.public.access
onedaywhen
external usenet poster
 
Posts: 124
Default Are there known issues with Vista and Acc2003

On Feb 28, 7:03 am, "Baz" wrote:
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.


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/lib...fice.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.


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.

--


  #16  
Old February 28th, 2007, 11:59 AM posted to comp.databases.ms-access,microsoft.public.access
Lyle Fairfield
external usenet poster
 
Posts: 36
Default Are there known issues with Vista and Acc2003

On Feb 27, 6:20 pm, "David W. Fenton"
wrote:
"onedaywhen" wrote roups.com:

What about, for example, back in 2000 when the "Access development
and support team at Microsoft" were saying things such as, "In
previous versions of Access, Data Access Objects (DAO) was the
primary data access method. That has now changed. Although DAO is
still supported, the new way to access data is with ADO."
(http://msdn2.microsoft.com/
en-us/library/aa140015(office.10).aspx)? My impression is that you
took the "no longer recommended" path and stuck with DAO, even for
new projects. Isn't it reasonable for someone to take the same
approach now with ADP, ADO, etc?


No, it is not.

HTH.

(think about the difference between a native technology and a
translation layer)

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


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?

  #17  
Old February 28th, 2007, 12:56 PM posted to comp.databases.ms-access,microsoft.public.access
onedaywhen
external usenet poster
 
Posts: 124
Default Are there known issues with Vista and Acc2003

On Feb 28, 10:59 am, "Lyle Fairfield" wrote:
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?


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.

--


  #18  
Old February 28th, 2007, 01:00 PM posted to comp.databases.ms-access,microsoft.public.access
onedaywhen
external usenet poster
 
Posts: 124
Default Are there known issues with Vista and Acc2003

On Feb 27, 9:53 pm, Tim Marshall
wrote:
What about, for example, back in 2000 when the "Access development and
support team at Microsoft" were saying things such as, "In previous
versions of Access, Data Access Objects (DAO) was the primary data
access method. That has now changed. Although DAO is still supported,
the new way to access data is with ADO." (http://msdn2.microsoft.com/
en-us/library/aa140015(office.10).aspx)


Try calling MS support now. They recommend DAO with jet.


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.


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.

--


  #19  
Old February 28th, 2007, 01:52 PM posted to comp.databases.ms-access,microsoft.public.access
Rick Brandt
external usenet poster
 
Posts: 4,354
Default Are there known issues with Vista and Acc2003

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


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.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com


  #20  
Old February 28th, 2007, 01:52 PM posted to comp.databases.ms-access,microsoft.public.access
Rick Brandt
external usenet poster
 
Posts: 4,354
Default Are there known issues with Vista and Acc2003

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


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.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 08:26 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.