Is MS Access (JET) suitable for multiuser access?

Question

I have a product designed to be a desktop product using MS Access file as a DB.

Now, some users need to install it in a few PCs (let's say 2 or 3) and SHARE the database.

I thought to place the MS Access file in a shared folder and access it from the PC, but... the JET Engine is designed for multiple user access?

Any tips or things to be aware of doing this?

EDIT: The app is a .net one, using the database as storage (not using the database as frontend)

Answer 1

Don't do it... the Jet database claims to be able to support multiple users, but it is incredibly easy to use the upsizing wizard to convert your Access file to a Sql Express database. That database file could EASILY become locked by a user or admin, and all of your users would be unable to use the database.

... and Sql Express is free. Your upgrade path from there to a full instance of Sql Server or some other commercial database is simple.

Answer 2

With 2 or 3 users on a reliable local network you should be fine, as long as you back the network drive up often.

Avoid any bit/bool fields in your tables - Jet has some nasty corruption issues with multiple access to them.

Also bear in mind that all locking in Access is optimistic: you will get dirty reads occasionally.

MS Access is designed for small office scenarios like this: non-critical light office use that you can set up with the minimum of programming.

Expect the data file to get corrupted every now and then - back up regularly.

Answer 3

The ACE/Jet engine is a great piece of software but, while it was designed to support multiple users, actually supporting multiple users in practise is not one of its strong points. The last straw for me is where then removed user level security (ULS) from the engine: I suppose I can imagine a simple database situation where all users will have the same privileges (i.e. admin access to all database objects) but IMO that is not supporting multiple users well, as compared with, say, MS SQL Server.

Answer 4

I can tell you from painful experience that Jet 3/3.5 was not reliable. I saw it crash frequently under light load and when there were crashes you risked data corruption. It used to be extremely sensitive to any power problems, any client crashing against it (even the UI linked to the mdb), and any LAN problems. More recent versions of Jet might be better but switching to Sql Server is clearly the way to go in my opinion for anything other than trivial data entry with a small number of users. Sql Express is free and you don't really lose anything, especially if you're UI is in .Net, rather than Access.

EDIT: Microsoft doesn't think you should rely on Jet 4 either.

from: http://support.microsoft.com/kb/303528

Microsoft Jet is not intended for use with high-stress server applications, high-concurrency server applications, or 24 hours a day, seven days a week server applications. This includes server applications, such as Web applications, commerce applications, transactional applications, and messaging server applications. For these types of applications, the best solution is to switch to a true client/server-based database system, such as Microsoft Data Engine (MSDE) or Microsoft SQL Server. When you use Microsoft Jet in high-stress applications such as Microsoft Internet Information Server (IIS), you may experience any one of the following problems: Database corruption Stability issues, such as IIS crashing or locking up Sudden failure or persistent failure of the driver to connect to a valid database that requires re-starting the IIS service

Answer 5

Jet does not have the sophisticated lock logic required to support multi-user scenarios. You can get away with using it if your application is mostly reads and low-contention.

I've seen websites support many users, but I would recommend SQL Express unless you have a compelling reason to choose Jet.

Answer 6

If you use a Terminal Server, the performance is real good. We have more solutions up to 50 Users at one Access mdb. Development is real fast and deployment easy.

Problems:

• everybody can copy data mdb
• no access rights
• limited store procedures
• optimize (compress and repair) only possible with no use data Database
• limit to 2 GB!