Performance issue when opening Acc97 Runtime MDB on Windows XP?

  • Thread starter Thread starter Tony Ciconte
  • Start date Start date
T

Tony Ciconte

I have developed an Acc97 application and distribute it using the Wise
installation system and SageKey scripts. The installations are rock
solid and the product works well on all types of systems.

However, we have notice a peculiar issue when running on Windows XP
systems. Specifically, it may take up to one minute to re-attach the
data tables from the network server. The application is split between
a front-end and back-end. This only happens on XP workstations. We had
long since taken the advice posted by Tony Toews in September of 2002
to attach the first table and open a recordset using it before
attaching the rest. We have a recent report from a client who runs a
Windows XP peer-to-peer setup where both the workstations and the
server are running XP. Their connecting times seem to be a longer
still.

Since this only happens on XP systems, I can only assume it related to
XP somehow. Are there any other tips when using XP to help this
situation? Does anybody know any XP settings that might affect it? We
have already done a search of Google and KB articles. The only
appropriate hit seemed to be the one from Tony Toews referenced above.

Any and all assistance is appreciated.

John Moore
DSI
 
This may sound strange but one of our clients had the
same problem. When they went to Access XP, the problem
went away. There must be some issue with how Access 97
runs and what Windows XP is expecting. j.
 
I have developed an Acc97 application and distribute it using the Wise
installation system and SageKey scripts. The installations are rock
solid and the product works well on all types of systems.
Click to expand...

Great stuff...who says you can't distribute a access application? (it is not
easy...but as you show...it can be done!).
This only happens on XP workstations. We had
long since taken the advice posted by Tony Toews in September of 2002
to attach the first table and open a recordset using it before
attaching the rest.
Click to expand...

Hum.., usually the above fixes the problem. I seen re-link times go from
about 6 minutes down to about 20 seconds. A remarkable little trick from
Tony's site.
We have a recent report from a client who runs a
Windows XP peer-to-peer setup where both the workstations and the
server are running XP. Their connecting times seem to be a longer
still.
Click to expand...

Hum, strange...as "usually" the "keep open" connection does the trick. Do
you know if this is occurring to "all" XP systems....or just some? (my guess
is only "some").
Does anybody know any XP settings that might affect it? We
have already done a search of Google and KB articles. The only
appropriate hit seemed to be the one from Tony Toews referenced above.
Click to expand...

Hum, gee the only thing that comes to mind would be perhaps some virus
software (the client could try disabling that for the test).

The other long shot (and mentioned at Tony's site) is you might want to
lower, or reduce the depth (length) of the path name. Apparently, with a
very long or "deep" dir nested way down in a lot of folders can be a real
source of problems (too much security checking occurs). So, too deep of a
folder path has been a real source of slow downs.

Also, you have to remember that windows 2000, or XP uses a complete
different operating system then does win9x. Each individual file and folder
in windows XP can have complete different security settings. I do have a
number of clients using access97, and the server is in fact NOT a server,
but just a pc running windows XP (PRO). So, I also have some peer to peer
setups. However, the one windows XP box is NOT used by anyone, and in fact
is a office file share server. However, with this setup I have NOT
experienced any performance problems when running the application. I have
not heard of any trouble with re-linking either. Of course, re-linking is a
rare, and one time event (you should not need to do it very often at all).
However, on those peer to peer boxes, I have no performance problems.

Is there any other details being left out (like perhaps they are using a
wireless hub for example?). I just recently fixed a real nasty performance
problem with a wireless hub by changing the frequency (the channel) since
another system next door was on the same channel. And, yes...I know I should
NOT be running ms-access across a wireless hub...but we are anyway!

Also, one more thing:

Please...if you do find the answer...can you share it with us? Tony will
most gladly include it in his list of things to check...and the whole access
community really benefits from people who share these solutions!


And, last but not least...any chance of slow network? You can read my
thoughts on networking and ms-access at:

http://www.attcanada.net/~kallal.msn/Wan/Wans.html
 
Albert D. Kallal said:
Hum, gee the only thing that comes to mind would be perhaps some virus
software (the client could try disabling that for the test).

The other long shot (and mentioned at Tony's site) is you might want to
lower, or reduce the depth (length) of the path name.
Click to expand...

Excellent suggestions.
Is there any other details being left out (like perhaps they are using a
wireless hub for example?). I just recently fixed a real nasty performance
problem with a wireless hub by changing the frequency (the channel) since
another system next door was on the same channel. And, yes...I know I should
NOT be running ms-access across a wireless hub...but we are anyway!
Click to expand...

Now that one is very interesting. And makes a lot of sense.

Thanks for the suggestion. Added.

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
 
Thanks to everybody for their responses. To answer a few questions
that were raised:

1) It is happening on all the XP systems running the app.
2) They are not running any wireless networks.

However, from the discussion, I realized that the attach code checks
to see if the attachments are already there and, if so, exits the
function. It does not actually get to the point (IN THIS ROUTINE) of
opening the first table as Tony suggests.

We are going to look at the rest of the start up procedure to see if
the initial table is being open as a recordset. If not, that could be
the problem. If so, we will add the open recordset code to an
appropriate point in the initial function and have the client give it
a try.

Again, I want to thank everybody for the help. If we are successful, I
will repost back to his thread.

TC
 
Back
Top