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

 

[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)

 

[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

 

[salad]

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

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

 

[salad]

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.

 

[Larry Linson]

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

 

[Daniel]

Take a look at

http://www.microsoft.com/office/com...f20a&mid=b4c5dd66-54c1-47f9-9b9f-2fac754a9788

I would also suggest you google group this one.

Daniel P

 

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

 

[David W. Fenton]

Sendkeys is not supported in Acc2003 programs running under Vista.

No serious programmer ever uses SendKeys.

 

[Larry Linson]

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]

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.

 

[David W. Fenton]

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)

 

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

 

[Lyle Fairfield]

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]

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!

 

[Lyle Fairfield]

No, it is not.

HTH.

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

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?

 

[Rick Brandt]

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.