MS Access (MDB) concurrency

Question

For a small project I need to utilize a simple database with very light requirements: few tables, no more than few thousands of records in total, 2 or 3 users. I am working

Answer 1

Access is really a desktop, single user solution. In practice, it has an upper user limit of "one".

It is also a local engine. That is, when you run a query, data is pulled across the network to the local JET engine for processing. An .ldb file is placed on the network share to control locks.

If you use a server side engine (MSSQL, MySQL, Sybase, 'Orable etc) then you submit a query to an engine that processes it and returns results to you. Locks are held internally.

This has huge implications for performance, stability and data integrity.

If your user decides to press the reset button, the Access databse has a fair chance of being corrupted and you'll have to delete the .ldb.

With a proper database engine (MSSQL, Sybase, 'Orable: I don't like MySQL's backups) then you also a proper backup capability. Unless you have some whizzy software to backup inuse files, it's possible you'll have no backups of you data in the Access DB.

I mentioned locks specifically because a db engine can handle concurrency and transaction far more efficiently and elegantly than any file-based system.

I can see using an Access project as a front end for a database engine, but not investing in a full client app with an Access backend.

Answer 2

When going with a network share I would go with a network enabled database (mysql/firebird/mssql) instead of access.

For the situation your describing using Access wouldn't be a problem.

I have used Access in more challenging situations then this mostly when working with websites when Access isn't abused beyond measure it really isn't that bad of a database engine. (not talking about forms and stuff like that just tables and records)

When your doing inserts/updates/deletes from several users at once then it gets a bit hairy. This is the point where you start to think about real database engines.

Also when you want a low overhead database which is thread safe you can have a look at vistadb (slower then access, not always free, 100% .NET)

I think access uses table level locks with some kind of queeing mechanism things should work ok. If your worried about it you can always throw a simulated stress test at it.

Answer 3

I have built a dozen or so small business apps in Access over the years. Most have a max of 10-20 users on them at a time. The databases are split between an "app" and a "data" database. Performance is decent and no problems with concurrancy. Also corruption has been basically non-existant since Access 2000 SP2.

There is a lot of people saying "don't ever use Access" - well if it is done right (ie by a professional developer) Access is quite a fine development package and I have made a good living at it. My customers are very happy with what I built.

Answer 4

I have been using Access, or more properly, Jet as a back-end on a very small, private site that can never grow as it is limited by the size of a profession in this small country. In three years I have not had any problems. There are less than 100 users, with about thirty to forty using it every day. The tables have a few thousand records.

Answer 5

I don't have much experience with Access, but this link may be useful to you:

http://office.microsoft.com/en-us/access/HP052408601033.aspx

"You can put the entire Access database on a network server or in a shared folder. This is the easiest method to implement. Everyone shares the data and uses the same forms, reports, queries, macros, and modules. Use this strategy if you want everyone to use the Access database the same way or if you can't support users creating their own objects."

"When you open an Access database file (.mdb) in shared mode, Microsoft Access also creates a locking information file (.ldb) with the same file name (for example, Northwind.ldb) and in the same folder as the database file. This locking information file stores the computer name (such as mypc) and security name (such as Admin) of each shared user of the database. Microsoft Access uses this information to control concurrency. In most cases, Microsoft Access automatically deletes the locking information file when the last user closes the database file."