By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,500 Members | 830 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,500 IT Pros & Developers. It's quick & easy.

slow database query

P: n/a
I have an access 97 database on a windows 95 platform and windows 95/XP
client that query on the database.
Client computer under 95 have not query problems but computer under XP are
very slow and made extra network traffic between client and server database
Could you say me why please
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
There is some interaction with networking between Win9x and NT that doesn't
go as well as it should. Place the back-end on an NT machine (NT4, Win2k,
WinXP) and you should get better performance and the 9x clients should still
work well.

--
Wayne Morgan
MS Access MVP
"Toto" <to**@wanadoo.fr> wrote in message
news:bu**********@news-reader1.wanadoo.fr...
I have an access 97 database on a windows 95 platform and windows 95/XP
client that query on the database.
Client computer under 95 have not query problems but computer under XP are
very slow and made extra network traffic between client and server database Could you say me why please

Nov 12 '05 #2

P: n/a
The user fix to restore performance back is to make sure that you keep a
connection to a table opened at all times FROM the front end, to the back
end.

Windows XP has a huge increase in file security stuff, and thus anything
that deletes, or creates a file TAKES a very long time! Since ms-access
constantly tries to delete and create the locking file, then a huge
performance hit takes place, as now ms-access is simply reduced to the speed
of the system to create/delete that locking file.

So, keep a persistent connection open, and things will perform like before.
In fact, you will generally find things performance EVEN better when you do
this.

I have run a97 on some new XP computers networks, and it absolute
screams....

So, when the application start-ups, just have it open a form to some table
in the back end, and either minimize that form, or even set it invisible.
You can also open a global reocrdset in code also. Regardless, anything that
forces the backend to stay opened to the front end will fix this problem.

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn
Nov 12 '05 #3

P: n/a
pl********************@msn.com (Albert D. Kallal) wrote in
<3InOb.152288$X%5.49959@pd7tw2no>:
The user fix to restore performance back is to make sure that you
keep a connection to a table opened at all times FROM the front
end, to the back end.

Windows XP has a huge increase in file security stuff, . ..
It does? What exactly? NTFS 5 was introduced with Win2K, so I don't
know of anything added in WinXP.

Certainly MS reorganized the user interface and altered the default
security configuration somewhat, but I don't know of any "huge
increase in file security."
. . . and thus
anything that deletes, or creates a file TAKES a very long time!
Er, on what basis do you make this statement? I see no such thing
happening in any versions of Windows.
Since ms-access constantly tries to delete and create the locking
file, then a huge performance hit takes place, as now ms-access is
simply reduced to the speed of the system to create/delete that
locking file.
I think this is simply not true.
So, keep a persistent connection open, and things will perform
like before. In fact, you will generally find things performance
EVEN better when you do this.
There as *always* been a performance drain from repeatedly
deleting/recreating the LDB file, and the performance hit has not
been changed by the OS.
I have run a97 on some new XP computers networks, and it absolute
screams....

So, when the application start-ups, just have it open a form to
some table in the back end, and either minimize that form, or even
set it invisible. You can also open a global reocrdset in code
also. Regardless, anything that forces the backend to stay opened
to the front end will fix this problem.


For what it's worth, I've tried this kind of thing in a few apps
and never seen any discernable effect on performance whatsoever.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.