[AccessD] Access XP and 97 hang on reattaching linked tables under WinXP

Marcus, Scott (GEAE, RHI Consulting) scott.marcus at ae.ge.com
Tue Mar 4 11:24:00 CST 2003


Seth,

I'm digging back to a few years ago...

I remember an issue similar to yours, very slow Access file performance and
sometimes even being locked out, on Netware. It had something to do with the
server cleaning up some type of file lock. It was set to every 24 hours (used to
be every 1/2 hour). Unfortunately, IM would not change the setting back to 1/2
hour because it was causing other performance issues when set that low.

I don't remember the name of the setting, I just remember the issue. I hope you
find your answer.

Scott Marcus

-----Original Message-----
From: Seth Galitzer [mailto:sgsax at ksu.edu]
Sent: Tuesday, March 04, 2003 12:15 PM
To: accessd
Subject: Re: [AccessD] Access XP and 97 hang on reattaching linked
tables under WinXP


Gustav,

Frankly, I can't believe it either.  File access has always been slower
on Win2K & XP machines, for all files not just Access files.  No amount
of tweaking has recitified this on those platforms.  It's just been
recently that we've seen similar lag on Win98 machines, but only with
Access linking to a BE on the server.  Other file access seems
unaffected.

Here's what we've been trying that seems to help a bit on the 2K/XP
machines:

Novell Client Properties:
	Advanced Settings
		File Caching: Off
		File Commit: Off
	Protocol Preferences
		Preferred Protocol: IPX

Network Properties:
	NWLink IPX/SPX/NetBIOS Compatible Transport Protocol
		Frame Type: 802.3
		Network Number: <our network number>

Registry:
Find the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComp
uter\NameSpace
It has multiple subkeys named with GUIDs.  Find the one that has a value
called "Scheduled Tasks". Delete that subkey.

These tweaks appear to reduce latency in opening files somewhat, but to
nowhere near that of previous Win9x performance.

On my Win98 machine, I just now tried moving IPX up in the Protocol
Order list under Protocol Preferences in the Client properties.  Along
with setting the frame type and network number in IPX settings, this
seems to have resolved the problem in that platform.

One thing I have not tried is to install the Client with IPX only
instead of IP & IPX.  I'll need to do some more checking first to make
sure that this won't interfere with using our NDSP printers or Zenworks
workstation management.

I have not tried setting up a small test lan.  I'm still convinced it's
a problem with the Client itself and not the server configuration.  I
have talked to other Novell admins around here (we all get together for
lunch once a week), and they don't have any answers either.  Novell's KB
is fruitless even if you can manage to find what you're looking for. 
I've seen many sites that list performance tweaks for this issue on
Win2K/XP and tried most of them, but none have helped to any significant
degree.

I'm as big a Novell fan as you'll find on this list.  But this problem
is driving me absolutely nuts.

Got any more tips for performance tweaking?

Seth


On Tue, 2003-03-04 at 09:41, Gustav Brock wrote:
> Hi Seth
> 
> I can't believe you're still struggling with this. We have never
> encountered a scenario that comes even close to what you describe.
> 
> Which protocol(s) are you running?
> Have you tried setting up an isolated test environment?
> (You can use a "Drew style" server for this!)
> 
> Don't you have a nearby Novell/database guru to work with on this?
> 
> /gustav
> 
> 
> > Relinking to a BE on Novell is panifully slow even on Win98 machines.
> > I've tried optimizing it, but it still takes up to four seconds for each
> > table on Win98, and even longer on 2K or XP machines.  Unfortunately,
> > the problem doesn't appear to be the relinker itself.  Using the
> > built-in Linked Table Manager is still painfully slow.  As a result I am
> > "this close" to moving everything to a real database server and using
> > ODBC.  Of course, ODBC is likely to introduce its own performance hit.
> 
> > I would love to have a discussion on this topic.
> 

-- 
Seth Galitzer			sgsax at ksu.edu
Computing Specialist		http://puma.agron.ksu.edu/~sgsax
Dept. of Plant Pathology
Kansas State University

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list