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

Speeding Up Access and Jet on a Network

P: n/a


If you have not seen it, this recent Microsoft Knowledge Base article is
worth reading:

http://support.microsoft.com/kb/889588

"How to optimize Office Access and Jet database engine network performance
with Windows 2000-based and Windows XP-based clients"

It is interesting how the 8.3 file format lives on and causes so many
slowdowns. Some fixes are simple registry tweaks. But the article does
explain the general observations that, for Access applications at least,
WinXP has been slower than Win2K, which has been slower than WinNT4.

Here are some of the suggestions for better performance:

Use short 8.3 file names and folder names in the first place. Apparently
Access calls the GetShortPathNameW API function for each append query when
there is a long file name (why?).

If you have long file names, convert your table links to use equivalent
short names (this latter probably requires enabling short name file
generation in NTFS on the server, which is the default situation).

In Win XP and Win 2K, enable long file name caching on the client machine,
i.e. set InfoCacheLevel to hex 10 (decimal 16) to cache all file names, not
just 8.3 file names. Why this isn't the default?

In Win XP, do not flush each single record individually on append queries,
i.e. on the client computer set DisableFlushOnCleanup to 1. Again, why isn't
this the default?

Connect using a mapped drive instead of a UNC path.

Turn off the file sharing violation notification delay, i.e. set
SharingViolationDelay and SharingViolationRetries to zero in the registry
for your server machine.

Put the back end on NTFS versus DOS.

Disable short name file generation in NTFS, i.e. set
NtfsDisable8dot3NameCreation to 1 on the server (not sure how this works
with converting long file name links to equivalent short names on the
client, as suggested above; perhaps no short names improves the call to
GetShortPathNameW?).

On Win 2003 Server, disable file aliasing, i.e. set NoAliasingOnFileSystem
to 1 in the registry.


Nov 13 '05 #1
Share this Question
Share on Google+
8 Replies

P: n/a
Crikey! (or something ruder). Do I have to tell my clients to do all
this to their machines? Fortunately we only use Access in preparing
and analysing the data (only??) and network performance isn't of the
essence here.
David

Nov 13 '05 #2

P: n/a
And I thought tweaking a SQL Server back-end was involved :-)

--
This sig left intentionally blank
Nov 13 '05 #3

P: n/a

"Stephen K. Young" <s k y @ stanleyassociates . com> wrote in message
news:35*************@individual.net...


If you have not seen it, this recent Microsoft Knowledge Base article is worth reading:

http://support.microsoft.com/kb/889588

"How to optimize Office Access and Jet database engine network performance with Windows 2000-based and Windows XP-based clients"


Click, whirr/hmmm. Saved.

Lots of good information there.

Apparently, 10 years after the introduction of the long file name,
Microsoft's programmers have yet to discover the usefulness of their
own extension to the O/S.
Nov 13 '05 #4

P: n/a
"Stephen K. Young" <s k y @ stanleyassociates . com> wrote in
news:35*************@individual.net:
Connect using a mapped drive instead of a UNC path.


This makes absolutely no sense, as mapped drives are resolved to UNC
paths.

Also, mapped drives ARE STUPID USER-HOSTILE HOLDOVERS FROM ANCIENT
DAYS OF DOS.

Maybe a mapped drive is a workaround for the problem of
non-top-level shares. That is, I've long known that putting MDBs in
top-level shares (instead of several directory levels down within a
share) is a big performance improvement.

They don't mention that one.

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

P: n/a
"Chris2" <ra******************@GETRIDOF.luminousrain.com> wrote in
news:aJ********************@comcast.com:
Apparently, 10 years after the introduction of the long file name,
Microsoft's programmers have yet to discover the usefulness of
their own extension to the O/S.


All I ever needed to know about long file names I learned from
examining the registry entries created by Office 97's installer --
they used the short filenames.

If MS doesn't trust them, then I don't trust them.

I also never use spaces in file names, but that's so I don't have to
worry about typing quotation marks at the command line.

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

P: n/a
> Connect using a mapped drive instead of a UNC path.


O-kay...

Now I would like to know the rationale behind this. Mapped drive are so
troublesome.
Nov 13 '05 #7

P: n/a
"Saintor" <sa******@REMOVETHIShotmail.com> wrote in
news:mL*********************@weber.videotron.net:
Connect using a mapped drive instead of a UNC path.


O-kay...

Now I would like to know the rationale behind this. Mapped drive
are so troublesome.


Microsoft has been known to post completely incorrect information on
their website.

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

P: n/a
"Stephen K. Young" <s k y @ stanleyassociates . com> wrote:
If you have not seen it, this recent Microsoft Knowledge Base article is
worth reading:

http://support.microsoft.com/kb/889588


Also see the Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

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
Nov 13 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.