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.
