Are there known issues with Vista and Acc2003

[Tony Ciconte]

I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate. I have seen posts indicating that Acc2003 MDBs should
work on Vista. However, our particular file has too many problems to
be viable on a Vista platform. Even converting it to an Acc2007 accdb
file has no positive effect.

I realize that Vista is new and should be avoided like the plague, but
we have few choices if some of our clients go to Vista.

We have been all over the MS knowledgebase and these groups without
much luck. Are there any lists of known issues and or suggestions
gathered during Vista beta that are available and if so, where?

Any and all help is greatly appreciated….

[Di Cook]

Tony

Sendkeys is not supported in Acc2003 programs running under Vista.

If you also set up shortcuts that performed a compact of the database you
will have to change the shortcut to "Run as administrator" or that wont work
as well.

Regards
Di
"Tony Ciconte" <to******@comcast.netwrote in message
news:ce********************************@4ax.com...

>I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate. I have seen posts indicating that Acc2003 MDBs should
work on Vista. However, our particular file has too many problems to
be viable on a Vista platform. Even converting it to an Acc2007 accdb
file has no positive effect.

I realize that Vista is new and should be avoided like the plague, but
we have few choices if some of our clients go to Vista.

We have been all over the MS knowledgebase and these groups without
much luck. Are there any lists of known issues and or suggestions
gathered during Vista beta that are available and if so, where?

Any and all help is greatly appreciated..

[aaron.kempf]

uh why would you ever have 50,000 lines of VBA?

have you ever heard of QUERIES?

keep your logic in QUERIES instead of in VB
and then you can have some hope of migration to a real backend (for
example, Access Data Projects and SQL Server)


On Feb 26, 12:07 pm, Tony Ciconte <[e-mail]:

I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate. I have seen posts indicating that Acc2003 MDBs should
work on Vista. However, our particular file has too many problems to
be viable on a Vista platform. Even converting it to an Acc2007 accdb
file has no positive effect.

I realize that Vista is new and should be avoided like the plague, but
we have few choices if some of our clients go to Vista.

We have been all over the MS knowledgebase and these groups without
much luck. Are there any lists of known issues and or suggestions
gathered during Vista beta that are available and if so, where?

Any and all help is greatly appreciated....

[aaron.kempf]

I would also start with the obvious:

for example:
a) remove DAO and rewrite it to ADO
b) move to Access Data Projects
c) use the index tuning wizard / database tuning advisor
d) run SQL Server profiler

I just find it comical that in the year 2007 anyone would be stuck
with 50,000 lines of VBA code.

I mean seriously here.

-Aaron


On Feb 26, 12:07 pm, Tony Ciconte <[e-mail]:

I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate. I have seen posts indicating that Acc2003 MDBs should
work on Vista. However, our particular file has too many problems to
be viable on a Vista platform. Even converting it to an Acc2007 accdb
file has no positive effect.

I realize that Vista is new and should be avoided like the plague, but
we have few choices if some of our clients go to Vista.

We have been all over the MS knowledgebase and these groups without
much luck. Are there any lists of known issues and or suggestions
gathered during Vista beta that are available and if so, where?

Any and all help is greatly appreciated....

[salad]

aa*********@gmail.com wrote:

uh why would you ever have 50,000 lines of VBA?

have you ever heard of QUERIES?

keep your logic in QUERIES instead of in VB
and then you can have some hope of migration to a real backend (for
example, Access Data Projects and SQL Server)

You probably build Northwind applications.

[Tony Toews [MVP]]

Tony Ciconte <to******@comcast.netwrote:

>I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate.

What specific problems are you having?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[aaron.kempf]

ROFL

that's funny

other than the fact that REAL SQL DEVELOPERS QUOTE PUBS NOT NORTHWIND

On Feb 26, 1:21 pm, salad <[e-mail]:

[e-mail] wrote:

uh why would you ever have 50,000 lines of VBA?

have you ever heard of QUERIES?

keep your logic in QUERIES instead of in VB
and then you can have some hope of migration to a real backend (for
example, Access Data Projects and SQL Server)

You probably build Northwind applications.

[salad]

aa*********@gmail.com wrote:

ROFL

that's funny

other than the fact that REAL SQL DEVELOPERS QUOTE PUBS NOT NORTHWIND

OK, you are a Pubs developer in your real job and working towards being
a Northwind macro guru when you tackle Access projects. I know you've
never written a commercial, complex event driven application, which is
what the OP has done.

Could his app be be done with less lines? Perhaps, but I find that
entirely irrelevant to his problem. Unless you have an undiscovered
method of executing queries to set and change properties and execute
events. I find your response ludicrous.

On Feb 26, 1:21 pm, salad <[e-mail]:

>>[e-mail] wrote:

>>>uh why would you ever have 50,000 lines of VBA?

>>>have you ever heard of QUERIES?

>>>keep your logic in QUERIES instead of in VB
and then you can have some hope of migration to a real backend (for
example, Access Data Projects and SQL Server)

You probably build Northwind applications.

[Tom van Stiphout]

On 26 Feb 2007 12:27:54 -0800, "aa*********@gmail.com"
<aa*********@gmail.comwrote:

Where did you read that DAO is not supported on Vista?
That ADP is preferred on Vista?

Statements like that don't give you much credibility here, unless
you're prepared to back them up.

50K lines of code is not excessive for a significant commercial app.
Not at all.

-Tom.

>I would also start with the obvious:

for example:
a) remove DAO and rewrite it to ADO
b) move to Access Data Projects
c) use the index tuning wizard / database tuning advisor
d) run SQL Server profiler

I just find it comical that in the year 2007 anyone would be stuck
with 50,000 lines of VBA code.

I mean seriously here.

-Aaron


On Feb 26, 12:07 pm, Tony Ciconte <[e-mail]:

>I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate. I have seen posts indicating that Acc2003 MDBs should
work on Vista. However, our particular file has too many problems to
be viable on a Vista platform. Even converting it to an Acc2007 accdb
file has no positive effect.

I realize that Vista is new and should be avoided like the plague, but
we have few choices if some of our clients go to Vista.

We have been all over the MS knowledgebase and these groups without
much luck. Are there any lists of known issues and or suggestions
gathered during Vista beta that are available and if so, where?

Any and all help is greatly appreciated....

[Larry Linson]

<aa*********@gmail.comwrote

>I would also start with the obvious:

for example:
a) remove DAO and rewrite it to ADO
b) move to Access Data Projects
c) use the index tuning wizard / database tuning advisor
d) run SQL Server profiler

I just find it comical that in the year 2007 anyone
would be stuck with 50,000 lines of VBA code.

And, I find it comical that anyone would recommend conversion to a
technology no longer recommended by the Access development and support team
at Microsoft -- as a solution to as-yet-unidentified problems, but problems
that appear to involve the internal interface to the Operating System.

That's a good many lines of VBA, but there's no indication that the VBA
code, or the quantity of it, has anything to do with the original poster's
stated problem.

And, there was no mention, IIRC, of the size and complexity of the Tables
and Relationships, nor of need for other features provided by a server
database.

I mean seriously here.

How can someone who has but one answer, and looks for opportunities to post
it, regardless of the applicability, if any, of that one answer to the
question asked, have the unmitigated gall to suggest that they are "serious"
about anything?

Larry Linson

[onedaywhen]

On Feb 27, 2:42 am, "Larry Linson" <[e-mail]:

I find it comical that anyone would recommend conversion to a
technology no longer recommended by the Access development and support team
at Microsoft

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?

Jamie.

--

[Baz]

Just goes to show how ignorant you are. Every form I create has a certain
amount of boilerplate, setup and housekeeping code, and all of that code has
error handlers. Then there's nearly always some validation code in the
BeforeUpdate event. Supposing that all this (at a modest guess) adds up to
150 lines per form, and that a reasonably mature application might contain
200 forms, and voila: 30,000 lines of code before even doing anything
clever, or even thinking about reports.

Not that I'd expect you to understand what I'm talking about since, by your
own admission, you don't even know what the Form Error event is for.
<aa*********@gmail.comwrote in message
news:11**********************@p10g2000cwp.googlegr oups.com...

>
I just find it comical that in the year 2007 anyone would be stuck
with 50,000 lines of VBA code.

[David W. Fenton]

"Di Cook" <[e-mail] in
news:45**********************@news.optusnet.com.au :

Sendkeys is not supported in Acc2003 programs running under Vista.

No serious programmer ever uses SendKeys.

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

[Larry Linson]

"onedaywhen" <ja**********@xsmail.comwrote

Isn't it reasonable for someone to take the
same approach now with ADP, ADO, etc?

Trying to pick a fight, again, Jamie? I thought we were going to try to
avoid that... oh, well, my misunderstanding -- I suppose it was just I who
was going to try to avoid it. Hmm, I never thought you were the one posting
as "aaron", either, but maybe that, too, was my misunderstanding.

So, here's the answer to your question: "Not if that person is knowlegeable
about Access and database in general, and has evaluated both approaches, as
many of us had done in the Access 2000 timeframe."

Larry Linson
Microsoft Access MVP

[Tim Marshall]

onedaywhen 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. As of 2005,
when I started using A2003, anyway.

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. There are, of
course, simpler apps that are also very important such as document
management systems. However, since about the early 90s, computer power
has been such that organizations rightly need to consolidate various
stand alone systems as much as possible so that both operational and
Decision Support information is more easily and quickly accessible.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

"onedaywhen" <ja**********@xsmail.comwrote in
news:11*********************@k78g2000cwa.googlegro ups.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/

[Baz]

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.

See if you can reply without resorting to juvenile abuse. Go on, I dare
you.

<aa*********@gmail.comwrote in message
news:11**********************@p10g2000cwp.googlegr oups.com...

I would also start with the obvious:

a) remove DAO and rewrite it to ADO

[onedaywhen]

On Feb 27, 8:01 pm, "Larry Linson" <[e-mail]:

I find it comical that anyone would recommend conversion to a
technology no longer recommended by the Access development and support team
at Microsoft

<<later>>

[but] Not if that person is knowlegeable
about Access and database in general, and has evaluated both approaches

OK, we now seem to be in agreement that blindly following the advice
of 'Microsoft support' is not the correct approach. I got the
impression from your early comment that you thought there was there
was direct causation between "going against the advice of Microsoft
support" and "deserving ridicule". That's why I stepped in (to break
up a fight, not to start one) and you clarified the point, for which I
thank you.

Jamie.

--

[onedaywhen]

On Feb 27, 11:20 pm, "David W. Fenton" <[e-mail]>
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)? 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.

Because...?

Jamie.

--

[onedaywhen]

On Feb 27, 11:20 pm, "David W. Fenton" <[e-mail]>
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.

--

[onedaywhen]

On Feb 27, 11:20 pm, "David W. Fenton" <[e-mail]>
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.

--

[Lyle Fairfield]

On Feb 28, 2:03 am, "Baz" <[e-mail]:

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.

[Lyle Fairfield]

On Feb 28, 4:01 am, "onedaywhen" <[e-mail]:

On Feb 27, 11:20 pm, "David W. Fenton" <[e-mail]>
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!

[onedaywhen]

On Feb 28, 7:03 am, "Baz" <[e-mail]:

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.

--

[Lyle Fairfield]

On Feb 27, 6:20 pm, "David W. Fenton" <[e-mail]>
wrote:

"onedaywhen" <[e-mail] innews:11*********************@k78g2000cwa.googleg 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?

[onedaywhen]

On Feb 28, 10:59 am, "Lyle Fairfield" <[e-mail]:

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.

--

[onedaywhen]

On Feb 27, 9:53 pm, Tim Marshall
<[e-mail]:

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.

--

[Rick Brandt]

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

[Rick Brandt]

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

[Jamie Collins]

On Feb 28, 12:52 pm, "Rick Brandt" <[e-mail]:

The attitude change from MS is simply a bit of validation to the arguments

You've hit the nail on the head.

Jamie.

--

[Lyle Fairfield]

On Feb 28, 6:56 am, "onedaywhen" <[e-mail]:

On Feb 28, 10:59 am, "Lyle Fairfield" <[e-mail]:

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.

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."

[Jamie Collins]

On Feb 28, 1:20 pm, "Lyle Fairfield" <[e-mail]:

JRO is an ADO component

[David W. Fenton] knows more about JRO than most

I'm an ADO advocate.

So David is an ADO user and advocate?

Take another look at what I wrote.

Jamie.

--

[Baz]

"Lyle Fairfield" <ly***********@aim.comwrote in message
news:11*********************@s48g2000cws.googlegro ups.com...

On Feb 28, 2:03 am, "Baz" <[e-mail]:

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.

Yep, right, whatever.

[Baz]

"onedaywhen" <ja**********@xsmail.comwrote in message
news:11**********************@j27g2000cwj.googlegr oups.com...

>
"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.

--

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

[onedaywhen]

On Feb 28, 2:39 pm, "Baz" <[e-mail]:

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

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.

--

[Baz]

"onedaywhen" <ja**********@xsmail.comwrote in message
news:11*********************@s48g2000cws.googlegro ups.com...

On Feb 28, 2:39 pm, "Baz" <[e-mail]:

I'm sure Vista contains lots of stuff for backward compatibility that MS

has

no intention of further developing.

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.

--

That I doubt.

[onedaywhen]

On Feb 28, 2:49 pm, "Baz" <[e-mail]:

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".

That I doubt.

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.

--

[Baz]

"onedaywhen" <ja**********@xsmail.comwrote in message
news:11**********************@h3g2000cwc.googlegro ups.com...

On Feb 28, 2:49 pm, "Baz" <[e-mail]:

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".

That I doubt.

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.

--

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".

[onedaywhen]

On Feb 28, 3:26 pm, "Baz" <[e-mail]:

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?

Like I said, for backward compatibility. What makes you think they WILL fix
problems?

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.

--

[Baz]

"onedaywhen" <ja**********@xsmail.comwrote in message
news:11*********************@k78g2000cwa.googlegro ups.com...

On Feb 28, 3:26 pm, "Baz" <[e-mail]:

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?

Like I said, for backward compatibility. What makes you think they WILL

fix

problems?

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.

--

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.

[Lyle Fairfield]

On Feb 28, 8:47 am, "Jamie Collins" <[e-mail]:

Take another look at what I wrote.

I have. It seems that what I read was not what you wrote. Thank you
for clarifying.

[David W. Fenton]

"onedaywhen" <ja**********@xsmail.comwrote in
news:11*********************@m58g2000cwm.googlegro ups.com:

On Feb 27, 11:20 pm, "David W. Fenton"
<[e-mail]:

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?

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. 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.

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

[Tony Ciconte]

Tony,

Thanks for the question and, to answer some of the other responders,
this is a commercial product that has been sold all over the country
since 1996. Most of that time we have used the Wise Installer with
SageKey scripts to place a solid runtime environment on the user's PC.
I am hopeful that the good folks at Sagekey will update their products
to handle Vista in the near future but until then my specific issues
are:

1) Performance is quite slow on a new Dell PC with 2GB, dual core
processor, Vista Ultimate and running an Acc2003 MDB under Acc2007.
2) The tabbed form doesn not always close and seems to refresh and
flash when closing on other occasions.
3) Screen resizing code (modResizeForm), fully attributed to Jamie
Czernik, does not always run properly. I suspect I can probably get an
update for this code if necessary.
4) Of course, the new ribbon plays havoc with the user interface and
placement of our custom tool and menu bars but we will have to live
with it unless somebody knows a way to change that behavior.

One other question...has anyone successfully implemented a runtime of
any previous evrsion of Access on a Vista PC with and/or without
Acc2007 installed?

Thanks again for any and all responses.

TC
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:

>Tony Ciconte <to******@comcast.netwrote:

>>I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate.

What specific problems are you having?

Tony

[Larry Linson]

"onedaywhen" <ja**********@xsmail.comwrote

>Like I said, for backward compatibility. What makes
you think they WILL fix problems?

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?

"Classic ADO", which is what you are discussing here, has been superceded in
the Microsoft world by ADO.NET, which is a different product entirely,
sharing only part of the name, and not based on OLEdb, as is classic ADO.
Whether it was a workable and usable technology (it was, though in my
personal opinion, no _better_ than DAO, even if each had unique features not
supported by the other) is not really material.

And, FYI, though my use of ADP/ADO has been less-than-extensive, I did not
encounter anything I needed to use that "just didn't work", but the fact
that Lyle thinks so well of it is a convincing argument for me that it had
potential that was "cut off in its prime" by corporate technical direction.
Lyle and I have had occasion to "cross words" (much less traumatic than
"crossing swords", BTW), but I have a high respect for his technical
judgement.

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".

* Access' Data Access Pages (DAP), on the other hand, were
so little adopted and used, that while existing DAPs are
supported, Access 2007 does not support creating new ones
nor maintaining the old ones. 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), so it has not
officially been "deprecated". It's just not something you want
to bet your future on.

Larry Linson
Microsoft Access MVP

[Lyle Fairfield]

On Feb 28, 1:43 pm, "Larry Linson" <[e-mail]:

ADO
can still be used (I am not, however, certain about Classic
ADO and the new ACCDB database format),

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.

so it has not
officially been "deprecated". It's just not something you want
to bet your future on.

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,

http://msdn2.microsoft.com/en-us/library/ms810810.aspx

entitled Data Access Technologies Road Map

because here's what Micorsoft says about ADO:

"ADO: ActiveX Data Objects (ADO) provides a high-level programming
model that will continue to be enhanced. Although a little less
performant than coding to OLE DB or ODBC directly, ADO is
straightforward to learn and use, and can be used from script
languages such as Microsoft Visual Basic® Scripting Edition (VBScript)
or Microsoft JScript®."

and here's what it says about JET:

"Deprecated MDAC Components
These components are still supported in the current release of MDAC,
but might be removed in future releases. Microsoft recommends that
when you develop new applications, you avoid using these components.
Additionally, when you upgrade or modify existing applications, remove
any dependency on these components.

Jet: Starting with version 2.6, MDAC no longer contains Jet
components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC
releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider,
or the ODBC Desktop Database Drivers."

and here's what it says about DAO:

"Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or
updated in several product releases and that will be excluded from
future product releases. Do not use these technologies when you write
new applications. When you modify existing applications that are
written using these technologies, consider migrating those
applications to ADO.NET.

The following components are considered obsolete:

Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic®,
Microsoft Visual C++®, and scripting languages. It was included with
Microsoft Office 2000 and Office XP. DAO 3.6 is the final version of
this technology. It will not be available on the 64-bit Windows
operating system."

I've posted these line several times before. I didn't make them up.
They are in a Microsoft article whose introduction is:

"This article describes the past, present, and future of Microsoft
data access technologies, including DB-Library, ESQL, DAO, Microsoft®
Data Access Components (MDAC) (including ODBC, ADO, and OLE DB),
ADO.NET, and SQL Native Client. This article identifies which
technologies are being enhanced, and which technologies and components
are being deprecated or excluded from future releases."

I think that MVPs should use their influence to have Microsoft tell us
the real story as revealed to the MVPs and their supporters, or the
MVPs should stop saying ADO is dead, because there are beginners here
who think that MVPs know what they are talking about. And in this case
it's clear; they don't, or Microsoft isn't fessing up.

[CDMAPoster]

On Feb 28, 5:59 am, "Lyle Fairfield" <[e-mail]:

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.

Was that a pun on vista :-)?

While it's true that the demographics of rich-yet-technologically-
naive companies on which Microsoft has depended is on the decline,
there are signs that Microsoft is changing for the better. A lot of
the impetus for Microsoft gaining so much market share was relying on
the fact that 99% of the time, large companies take the easiest way
out. It's very impressive how Microsoft went about leveraging the
advantages they had. As companies get more technologically savvy
they're not willing to pay the highest costs associated with ignorance
and the "easy" way. I think Microsoft sees that gradual change in the
market and are fighting to hang on to potentially fleeing customers.
It's just too bad that Microsoft had to adopt this attitude under
coercion, kicking and screaming, because I believe they've always had
the talent available to create exceptionally fine products. Microsoft
is learning that the current product buggy life-cycle path is rapidly
becoming inadequate. I think they'll be able to take steps to replace
the old paradigms. IMO, their having a prioritization plan in place
for fixing bugs in current products based on a set of metrics (future
revenue? :-)) is one of those steps. That shows that their focus is
on the bottom line -- where it should be. Of course, had they taken
these steps earlier they would have missed out on some extra revenue
due to the number of customers willing to "ride" that particular
treadmill. Microsoft is not stupid and will adapt their ways to ways
that make the most money for a given software environment.

Even UNIX land is no panacea. UNIX implementations, until Microsoft
showed how to make things easier for the user, were a nightmare to use
compared to the ease of things today. Without Microsoft being there
to help redefine OS priorities and reshape user expectations UNIX
usability would not be where it is today. So much for
conscientiousness. UNIX still has a way to go in providing
convenience for users and developers. Although some might say
that .NET is Microsoft's attempt at pushing their bugs beyond the
local machine, it has the capacity to bring convenience to an
inconvenient web world.

Open source is garnering the best ideas from Microsoft, Microsoft is
trying to implement the best ideas from open source, and I'm trying to
get the best from both :-).

Oh, the topic! I never dismiss DAO or ADO before looking at a
project's current and projected requirements. Er..., the topic! I
have not used Vista yet but I plan to buy a machine (I know it won't
run well on old machines) soon to run it (not a home version of Vista)
at home. Until I start discovering my own set of issues I will be
acutely interested in the experiences of others. I note that the
plethora of Vista versions will make it harder to generalize about how
various Access versions will run under Vista. I.e., I suspect that
there will be a dilution of OS specific experience.

James A. Fortune
CD********@FortuneJames.com

[Michael]

It may not be related to Vista. I work with another product developed
in Access with about 15K lines of VBA code -- using DAO. After I
installed Office 2007 on a Windows XP machine (no previous version of
Office has been installed on it), I have found this product to be
nearly unusable in Access 2007 because of slow performance in forms.
The same product works fine in Access 97, 2000, XP, and 2003. I get
the same results whether I keep the 2002-2003 file format or convert
it to the 2007 format. Thus far, no Access MVP has been able to offer
any insight on what might be the problem.

On Feb 28, 11:14 am, Tony Ciconte <[e-mail]:

Tony,

Thanks for the question and, to answer some of the other responders,
this is a commercial product that has been sold all over the country
since 1996. Most of that time we have used the Wise Installer with
SageKey scripts to place a solid runtime environment on the user's PC.
I am hopeful that the good folks at Sagekey will update their products
to handle Vista in the near future but until then my specific issues
are:

1) Performance is quiteslowon a new Dell PC with 2GB, dual core
processor, Vista Ultimate and running an Acc2003 MDB under Acc2007.
2) The tabbed form doesn not always close and seems to refresh and
flash when closing on other occasions.
3) Screen resizing code (modResizeForm), fully attributed to Jamie
Czernik, does not always run properly. I suspect I can probably get an
update for this code if necessary.
4) Of course, the new ribbon plays havoc with the user interface and
placement of our custom tool and menu bars but we will have to live
with it unless somebody knows a way to change that behavior.

One other question...has anyone successfully implemented a runtime of
any previous evrsion of Access on a Vista PC with and/or without
Acc2007 installed?

Thanks again for any and all responses.

TC
"Tony Toews [MVP]" <[e-mail]:

Tony Ciconte <[e-mail]:

>I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate.

What specific problems are you having?

Tony- Hide quoted text -

- Show quoted text -

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.comwrote

>ADO can still be used (I am not, however, certain
about Classic ADO and the new ACCDB database
format),

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.

Thanks for the reminder, Lyle. I'd forgotten about your post on the subject

>so it has not officially been "deprecated". It's just not
something you want to bet your future on.

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,

http://msdn2.microsoft.com/en-us/library/ms810810.aspx

Good suggestion, Lyle. I believe you'll find some conflicting information,
perhaps in the Access 2007 blogs -- it's a massively vast website, and I'm
not surprised that not all pages are up-to-date. The one you cite here
shows a most-recent-date-of-update of December 2004. I will forward the
suggestion, with my "endorsement" that it is a good idea to make the website
consistent and consistent with current recommendations, to a contact at
Microsoft.

HOWEVER, bear in mind that "If you are looking for someone with a little
influence at Microsoft, you've come to the right person, because I have as
little as anyone."

Larry Linson
Microsoft Access MVP

[Rick Brandt]

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

[onedaywhen]

On Feb 28, 6:43 pm, "Larry Linson" <[e-mail]:

Thanks for this upbeat reply, Larry. My original impression was that
you were ridiculing people such as Lyle who had bought in to ADP but
I'm glad see that is not your prevailing position.

"Classic ADO" ... has been superceded in
the Microsoft world by ADO.NET

It's no big deal but your use of the word 'superseded' is debatable.
I'll give you

<'Lifestyle choice' CLR language>.NET + ADO.NET

has superseded

VB6.0 + ADO Classic

but that would be OT, of course. We're talking about Access and

VBA6 + ADO.NET

don't really go together, so AFAIK in the Access world ADO Classic has
not been superseded by ADO.NET until Access gets a '.NET For
Applications' IDE (if it ever does).

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".

I'm in broad agreement except I'm perhaps less optimistic (if that's
the word) about ADO fixes other than ensuring backward compatibility
on Vista. I expect any fundamental problem discovered in MDAC 2.8
(other than 'security issues') to be left in the 'code museum'.

I think the best outcome for the Access world is for DAO to supersede
ADO. If you want me to agree ADO out of favour with the Access
development team and is DAO the future then you've got it. But the
future isn't here yet <g>: DAO still hasn't caught ADO in terms of
properties/methods/events and Jet functionality. ADO still works so it
seems reasonable to me to keep using it until DAO supersedes ADO. We
need people such as yourself, Larry, to keep the pressure on the
development team to get DAO up to speed :)

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)

ADO and ACCDB seem to work well using the new and specific OLE DB
provider, Microsoft.ACE.OLEDB.12.0 (it even works well 'stand alone'
-- i.e. without Access installed -- which we were earlier advised
would not be possible plus it is available as a 'free' download). No
doubt there will be bugs in the new provider, as is almost inevitable
in 'version 1.0' software, but there is a high expectation they will
be fixed.

[ADP is] just not something you want to bet your future on.

I know someone who is in a real dilemma about this one. They bought
into ADP, converted mission critical apps from MDB to ADP and now
really don't know whether for new projects to go for the untried (by
them) MDB + SQL Server linked tables or stick with their ADP approach
(which has worked really well for them) at least for the short term.

>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? Anyone?

Jamie.

--