Networks

Question

Gravatar
Locked

MS Access won't multitask with SME Server

By brennan2004 ·
We have a half dozen Win XP computers on a network that that includes a SME Server running in file-server mode only. There are no other problems with this setup other than an MS Access 2003 application that is unable to multitask ? a second computer trying to update the database will either run very slowly or hang. Please note the following:
1. The Access application is setup with the programs on the client computers, sharing the data file on the file server
2. This application was previously running smoothly on another linux file server installation. The only initial changes were to set up new map drives, and change the pointers within the Access application to the folder on the new server.
3. The SME forum helped me add VetoOplockFiles /*.mdb/*.MDB/ to the file: /etc/samba/smb.conf of the server
4. That failing to resolve the problem, they have suggested adding this registry entry to the Windows clients:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters]
"OplocksDisabled"=dword:00000001
5. Interference from the Antivirus or Firewall have been ruled out

Any further suggestions welcome
Thanks
John

This conversation is currently closed to new comments.

5 total posts (Page 1 of 1)  
+ Follow this Discussion ·
| Thread display: Collapse - | Expand +

All Answers

gravatar
Collapse -

You are describing the way that Access works

by OH Smeg In reply to MS Access won't multitask ...

It doesn't like several different users attempting to edit the same Data File as it was never designed to work that way.

When the Nix Server was hosting this file are you sure that it wasn't also hosting a Back End SQL Application that Access was interfacing with as a Front End? That is how I would make cheap inferior Software work for a business.

Col

gravatar
Collapse -

Of course it won't

by Tony Hopkinson In reply to MS Access won't multitask ...

Access is a single user desktop application.
Putting the file on some common machine, doesn't make it multi user and it's client server model is simply OS read/write locks on the MDB file itself.

That's like putting a text file on a server and having ten people update it at the same time with notepad!

Oplocks disabled will just make things worse, all that will do is corrupt the MDB faster.

Probably your most cost effective option is to move the access database in to a sql server instance and then use accesses links option. SQL Server will deal with multi user, and if you are reasonaby fortunate you won't have to make any changes to your front end.

HthS

gravatar
Collapse -

MS Access is not the source of the problem

by brennan2004 In reply to MS Access won't multitask ...

Thank you for your responses, but I am rather surprised at the focus of your replies, in particular that Access does not work in a multi-user environment. (perhaps a better word that multi-task).
I have just run a test linking a couple of windows work stations with the data file on another windows workstation and they ran like a charm. The computers edited adjacent records in the same table without complaint or noticeable slowness. And I had not applied any oplock registry adjustments to the computers involved.
Further as I said, the program was running fine on the previous server (I think it was Debian flavour of linux ? set up by someone who abandoned the organization and took the keys).
So I think that resolution of the problem lies somewhere else.

gravatar
Collapse -

I think you'll find that the Nix Server

by OH Smeg In reply to MS Access is not the sour ...

Was running SQL on it as the Back End and that the Access was the Front End that was used by the End Users.

This is quite a common thing to do and even M$ does this with their SQL Server. The only difference is the Licensing Costs.

Samba is only required to allow the Windows Systems to communicate with the Nix Server so you are stuck with the software.

Here Access is defiantly not designed to have several different systems edit the Same Data File no matter what may happen in limited Tests. If the Data is edited at the same time you are going to have problems and it doesn't even need to be in the same field just the same Work Book or whatever they call Access Files.

Col

gravatar
Collapse -

May be not this particular one, but rest assured

by Tony Hopkinson In reply to MS Access is not the sour ...

you use access for an application like this, the wheels will come off, there is no multi-user in the design of access, it's relying on whatever machine you locate the file. Desktop databases are notorious for f'ing this up.

Google corrupt access mdb, for confirmation.

Back to Networks Forum
5 total posts (Page 1 of 1)  

Start or search

Related Discussions

Related Forums