I have been asked to develop an Access database that would be used by up to 12 people simultaneously. I have had advice that I shouldn't do this as Access is unreliable when there are more than 3 or 6 or 10 users (pick a number depending on where you do your research). Others don't think it's a problem.

I know the theory but I have personal experience of working in a 20 user Access environment, a call centre where use was heavy, everybody logged call outcomes to the same Access table. There was no problem, other than the occasional record lock out.

Is this multi-user issue a theoretical problem blown out of proportion? Does anybody have actual experience of multi-user problems rather than theoretical worries?

Thanks in advance for any contributions.

Kind regards.

Kevin Mawdesley

It's an "It depends" answer.

If the user access is reading data, 30 or 40 simultaneous users isn't really a problem

Writing is a whole different ball game and when you need record/file locking.
Is this going to be a web application, desktop client/server app, or something else?

Originally Posted by RedWharf

Does anybody have actual experience of multi-user problems rather than theoretical worries?

Possibly. How will your application be used? What is its nature? What do you expect the read to write ratio might look like? How many records, and how will they be distributed among the (how many) tables?

Access isn't the best. It isn't the worst. It has a (somewhat) weird stigma, like the WalMart of programming frameworks. Many programmers think Access is simply beneath them, and look down on it, and anyone who might use it. A lot of the advice you'll see to avoid Access is dogma, pure and simple.

That doesn't mean it will necessarily work for you. I've seen it work fine in 100 user scenarios, and come to its knees with 5 users. The design of the system is more important than the tools used to build it, as with anything else in life. But, Access is weak at scalability both in terms of data size, and concurrent users. If you have a lot of data, a look of record seeks, and a lot of data manipulation, with most users needing the same rows at almost the same time, Access will be a bad choice.

For 12 users and a typical database application, I would expect Access to work admirably. And cost 1/2 to 1/3 as much to build, purely in terms of development effort and time.

Thank you for your replies.

I don’t see this as a heavily used application, maybe 100 posts per day in total from all the users. Users will mostly access the records they have posted themselves.

The backend of the split database will sit on a shared network drive, the frontends on individual PCs.

This isn’t a complex application, one main table logging user interaction with various clients. The advantages of using access are, as is mentioned, that the system can be developed much more quickly and cheaply. I do agree that Access seems to have a stigma. To me it’s a simple, effective and flexible tool that is so much easier to develop with than, say, PHP/HMTL/SQL.

Kind regards,

Kevin Mawdesley

Hi Kevin,

Where I currently work, the entire quality control and customer services departments use an Access database. There's normally around 10 users connected on any one time, along with a lot of read/write queries each day.

The person is charge says he doesn't have any problems with it what so ever.

Provided the queries are kept from holding the connections open for longer than absolutely necessary, sounds like there should be no problems.

Access is usually slagged off by the people who try to use it as a highl powered database server. It's never going to be suitable for 1/2 million row tables with multiple joins, but that isn't it's real purpose.

Originally Posted by RedWharf

I don’t see this as a heavily used application, maybe 100 posts per day in total from all the users. Users will mostly access the records they have posted themselves.

Especially with the last bit, this means locking should almost absolutely never be an issue for you.