Odd problem loading Access 2000 DB over a LAN

[stephann]

Hi there,

I was prompted to join the forum as it looks as though members give very helpful, constructive advice!

My problem with Access 2000 is slightly odd. The database file is installed in a shared network folder (which I have verified that both computer 1 and 2 have full access to). Both computer 1 and 2 are both running the same OS (XP).

If I load the database first on computer 1, then try to load it on computer 2, clicking on the database icon (or trying to load it directly from MS Access 2000) does nothing. But if I load it first on computer 2, then on computer 1, it loads fine on both computers (and works fine over the LAN).

Currently the database is set in Microsoft Access to 'shared' (not exclusive) and 'no locks.'

I've also tried splitting the database, but the same problem occurs when trying to load the FE on computer 1 first (and just to put your minds at rest, I will be using the split version when fully implemented)!

Thanks in advance for any advice offered.


Stephann

 

[RuralGuy]

When you are running a split FE/BE database over a lan, everyone should have their own copy of the FE on their own PC.

 

[stephann]

Thanks RuralGuy but, yes, each PC has a copy of the FE installed. This problem seems to happen regardless of whether the database has been split or not.

 

[RuralGuy]

WinXP Pro or Home Edition?

 

[stephann]

Both PCs that I tried accessing it from are using XP Professional.

 

[RuralGuy]

All users need full rights: read/write/edit/delete

 

[stephann]

I'm assuming that all users DO have full rights (on both PCs, going to the 'User and Group Permissions' menu in Access 2000 shows me that the current owner for all items is 'admin' and that 'admin' is the current user. 'Admin' also has full read/write/modify/administer permissions. Is there anything else I need to check?

 

[RuralGuy]

That all looks ok to me. Boy I've sure seen this symptom discussed before but I can't locate one of the threads. I'll keep looking.

 

[RuralGuy]

Do you have the same problem if you open both while holding down a <SHIFT> key which will bypass any startup code/form?

 

[ByteMyzer]

Do both machines have Office 2000 SP3?

http://www.microsoft.com/downloads/...70-47D0-4306-9FA4-8E92D36332FE&displaylang=EN

 

[Atomic Shrimp]

Where is the shared network folder hosted? Is it on another PC acting as server, on a NAS device, or on a file server? (if so, what kind?)

 

[stephann]

Thank you all very much for your help so far with this. To answer your questions:

- I've tried updating all PCs with Office 2000 SP3 and the problem still persists.
- As far as I can tell, the LAN is running on a Buffalo LinkSatation LS-G338 (I *think* the model number is right) file server.
- The unsplit database do not load when shift is held. As far as I can tell, the unsplit database never loads from the network shared folder, but sometimes loads when copied to individual PCs.

Now then, to clarify what I've tried a bit more (and the problem):

1) Originally, I copied an unsplit version of the database to a shared folder on the network, which I was sure all PCs had full rights for. If the database was opened on PC1 first, then PC2, it would work fine and I could perform record edits etc. over the network. If the database was opened on PC2 first, then PC1, the version on PC1 wouldn't load at all (it wouldn't freeze or anything - it just wouldn't load).

2) I tried splitting the database - copying the FE (containing everything apart from the tables) to each PC and the back end (containing only the tables) to the shared folder on the network. I then linked the tables. The split version has a similar (but not identical problem). In this case, the main menu of the database loads on both PCs, but the main form (with a lot of VBA code) will not load on a PC if it has already been loaded on another PC on the network (it causes MS Access to say 'not responding' and all I'm able to do is close the program down). As soon as I close the form on one PC, the other PC is able to load it. Note that whilst it took around 1.5 seconds for the main form to load over the network in the unsplit version, it not takes around 30 seconds (unacceptable) in the split version.

So, any more ideas guys? Although I'm only running tests on 2 XP Professional machines at the moment, there are 2 more PCs on the network (1 with XP Professional, 1 with Vista).

My next step will be to try to resolve the performance issues using links such as:

http://www.granite.ab.ca/access/performancefaq.htm and
http://support.microsoft.com/kb/889588

But, of course, the first thing I need to do is get it working over the LAN - at any speed!

 

[ByteMyzer]

Wait a minute, are you having these problems over a LAN (Local Area Network, same building/office/etc.) or a WAN (Wide Area Network, offsite, different building/office/etc.)? You should not be having these problems over a LAN (and you really shouldn't be trying to use mdb's as your data source over a WAN; you should consider a solution like MS SQL).

 

[stephann]

Wait a minute, are you having these problems over a LAN (Local Area Network, same building/office/etc.) or a WAN (Wide Area Network, offsite, different building/office/etc.)? You should not be having these problems over a LAN (and you really shouldn't be trying to use mdb's as your data source over a WAN; you should consider a solution like MS SQL).

It's a LAN in a small office, currently with 4 PCs connected.

 

[ByteMyzer]

Would it be possible for you to attach a copy of the database FE for us to look at? If so, we could look at it and tell you how you might modify it for better performance.

 

[stephann]

Sure. I'll post it as soon as the guy that designed it finishes trying to optimise it. In the meantime, any comments on the more pressing issue (of it not loading at all over the network) would be welcome.

 

[ByteMyzer]

We won't be able to tell you anything more meaningful without seeing the database, hence my question.

 

[stephann]

No problem. I'll send a version of the database over the next few days, after we've tried many of the common ways of optimising as discussed in the links I posted.