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 supposed to be multi-user - I think Microsoft recommend it for up to 4 or 5 users, but in practice I'd recommend that you never use an Access database where there is more than a single user, although if you really don't have the choice it's acceptable for two or three, given certain provisos.

I've had experience of four or five systems using an Access database back-end - all acquired from other 'developers' - and in all cases I've moved them to SQL Server as the as a priority after any immediate updates and fixes required when taking the contract - generally as soon as I could talk the boss paying the bill into it. Time span for that is usually several months, so I have seen it running concurrent for a reasonable length of time under several different applications.

Actually it will generally work passably well if the system does not have a lot of concurrent inserts/update and is not heavily used. The chief practical problems in my experience are..

1. It's liable to corruption - it just does. Generally this isn't too much of a problem as opening the file and running compact and repair will sort out the issues, but a good backup regime is absolutely essential.

2. It's slow. Every time I've upgraded a system to SQL Server I've received a lot of kudos for speeding up the system from the users.

3. The database file bloats because of the way that Access marks records as updated or deleted. This further slows the system as the file has to be loaded across the network. Consequently some regime that compresses the data, usually on a daily basis, is essential.

All of the above are much less of a problem with single user systems as the underlying issues that prompt these are much less prominent.

All in all I must emphasise that I would never recommend Access for any multi-user system. However if really have too you'll probably get away with it so long as it's a lightly used application and you do institute the backup and maintenance procedures.

Answer 2

This is an old question, but nobody has ever actually answered it. Here are the questions:

1. How are concurrent reads handled in MDB?
2. How are concurrent updates/deletes handled in MDB?
3. Is there a concept of locks and how can I leverage it in a .NET app?
4. Is placing the MDB file on a network share good or horrible idea?

The first two questions can basically be answered with one explanation. One key caveat here: the answers I'm giving here are specific to Jet MDBs (and their variants) and do not completely apply to the new file format introduced starting with A2007, i.e., ACCDB format. I have not fully explored the implications of the removal of Jet ULS from the ACE and some of the comments below may assume Jet ULS below the hood. For a lot of things, though, you can substitute "LACCDB file" for "LDB file" and the results will be the same.

1-2) Concurrent reads/updates/deletes

The Jet database engine is often referred to as a "file server" database in that there is no server-side demon managing I/O with the data files on the server. What this means is that all clients using a Jet MDB are reading the file directly.

That is, of course, a recipe for disaster if there's not some mechanism built in for handling concurrent access to the file.

Jet uses a record-locking file, where if your MDB is "MyFile.MDB" the record locking file will be in the same folder and called "MyFile.LDB". The LDB file records what Jet ULS users have the MDB file open, what workstation that user is connected from, and all the information necessary for negotiating concurrency issues.

Now, to those who cut their teeth on client/server database engines, this may seem primitive and dangerous, but at the time the Jet database engine was developed, its purpose was to be used as a desktop database engine for small workgroups, and it was competing with other desktop db engines like xBase and Paradox, both of which used analogous locking files to manage concurrent use of data files from multiple clients.

Within a Jet database file, locks are applied either on data pages (which in Jet 4 were increased to 4K, whereas in Jet 3.x and before, they were 2K), or at the record level if the data table was originally created to use record-level locking. In the early days of Jet 4, record-level locking was found by many to be quite slow, particularly when using pessimistic locking, so a lot of Access developers never used anything but page-level locking (@David Fenton raises hand!).

In fact, when using optimistic locking, you avoid most of the concurrency issues that would come with pessimistic locking.

Some caveats:

1. from DAO, record-level locking is unavailable, and you only ever get page-level locking.

2. from DAO, there are a number of options for controlling optimistic/pessimistic locking, in particular the LockEdits argument of the OpenRecordset method, but that also interacts with certain of the setting specified in the OpenRecordset Options argument (e.g., Option dbReadOnly cannot be used with LockEdits). In addition to locking, there are also options for consistent/inconsistent updates, and all of this can interact with transactions (e.g., changes within an uncomitted transaction are not going to be visible to other users and thus will not conflict with them, but it can put read-only locks on the tables involved).

From ADO/OLEDB, these Jet concurrency control structures are going to be mapped onto the relevant functions and arguments found in ADO/OLEDB. Since I use Jet only from Access, I interact with it only via DAO, so I can't advise on how you control these with ADO/OLEDB, but the point is that the Jet database engine offers control of your record locking when accessing it programmatically (as opposed to through the Access UI) -- it's just more complicated.

3) Locks and .NET

I can't offer any advice here, other than that you'd likely use OLEDB as your data interface, but the point is that the locking functionality/control is there in the db engine itself, so there's likely a way to control it via OLEDB. It may not be pretty, though, as it seems to me that OLEDB is designed around client/server architectures, and Jet's file-based locking may not map onto that in an elegant way.

4) MDB on a network share

Jet is very sensitive to the slightest hiccup in any network connection. Because of that, low-bandwidth networks can increase the vulnerability of Jet databases open across a slow connection.

This is because major chunks of the database file have to be pulled across the wire to the local computer's RAM for processing. Now, many people erroneously claim that the entire MDB file is pulled across the wire, or that whole tables are pulled across the wire. This is not true. Instead, Jet first requests the indexes (and requests no more than necessary to fulfill the query) and then from that result determines exactly which data pages are needed and then pulls only those pages. This is surprisingly efficient and fast.

Also, Jet does some very intelligent caching that can mean that a first data request can take a while, but subsequent requests for the same data happen nearly instantaneously because of caching.

Now, if you haven't indexed your tables well, you may end up pulling the whole table and doing a full table scan. Likewise, if you base criteria on client-side functions that are not part of Jet's SQL dialect, you could end up pulling a full table (sorting on, say, Replace(MyField, "A", "Z") is likely to cause a full table scan). But that kind of thing is going to be inefficient with a client/server architecture, too, so it's just common-sense schema design to index things properly and be careful with using UDFs or non-Jet-compatible functions. In general, the same things that are efficient with client/server are going to be efficient with Jet (the major difference being that with Jet you're better off with a persistent connection in order to avoid the overhead of recreating the LDB file, which is significant).

The other thing to avoid is trying to use Jet data across a WiFi connection. We all know how unreliable WiFi is, and it's just asking for trouble trying to work with Jet data across a WiFi connection.

The bottom line:

If you're using an MDB as a data store to serve data from a web server, you should put the data as close to the web server's RAM as possible. That means that where possible, on a disk volume that is attached to the physical web server. Where that's not possible, you want a fast, reliable LAN connection. GB LANs in data centers are pretty common these days and I'd be very comfortable working with Jet data across that kind of connection.

For shared use, e.g., multiple client workstations running a VB.NET desktop app sharing a single Jet MDB as data store, it's pretty safe to have the data file on a reliable file server. Where possible, it's a good idea to put your Jet MDB files on machines that aren't serving multiple purposes (e.g., your domain controller that is running Exchange, SQL Server and acting as file server and print server may not be the best location). Apps like Exchange can badly interfere with file server functionality, and I'd usually recommend never putting MDB files on a server that is multi-tasking as an Exchange server unless it's extremely low volume.

Other considerations:

1. never try to distribute an MDB on a replicated file system, unless all users are using the same replica. That is, if you have two servers replicating files between them, don't even think about editing the MDB file from both servers. This will corrupt the file almost immediately.

2. I would recommend against storing any MDB on anything other than a native Windows file system served via native Microsoft SMB networking. This means no Novell, no Linux, no SAMBA. The key reason for this is that there are apparently low-level hooks from Jet into some low-level locking functionality in the Windows file system that are not 100% replicated on other file systsm. Now, I'm very conservative on this, and many competent Access developers have reported excellent results with properly-configured Novell file servers (often there need to be some record-locking adjustments, though that may be less relevant these days -- I don't even know if Novell exists any more!), and blazing performance with Linux-based file servers running SAMBA. I'm cautious on this and would recommend any client against it (this includes various SAN devices, as well, since not a lot of them are Windows-based).

3. I would never run them on any virtualized file system for the same reasons. However, I've got a client who has been running her single-user Access app under Parallels on a Mac Air for several years now without a single problem. But it's single-user, so the locking issues are going to be relatively minor.

I don't know if that answers your questions or not. It's all based on my 13 years of regular use of Jet as an Access developer and study of the only published book on Jet, the Jet Database Engine Programmers Guide (for Jet 3.5 only). I haven't provided any real citations, but if anybody needs some details on anything I've said, I'll do the research if I can.

Answer 3

It's already been stated several times to use a real multi-user, free database platform. But one of the reasons why has not been stated. This reason is, how many existing, messy, troublesome, large Access databases have started out as "a few records, one or two users max"? I'd venture to say all of them.

Unless there are only two or three employees in the whole company, the odds are that if you develop a useful piece of software, it's going to eventually be used by more than the original two or three users, have more than the original few thousand records, and will expand over the years to include many forms, many more tables, and much more data. You can't redo the foundation of a house once the house is built. Build a strong foundation today, and you can expand the house to your heart's content. Same for software.

Answer 4

Please don't use Access for a multi-user scenario.

I've just gone through two weeks of pain because my predeccessor on a project chose Access as a back end.

Concrete reasons:

• There is no such thing as Linq-to-Access
• Access has numerous quirks like dependencies on the order of addition of parameters to commands that will take you ages to debug
• Access doesn't scale
• Database updates are a chore when compared to using SQL Server

Answer 5

I think you can define it in your .net application connection string. I googled for JET, access and record locking

here's a link that might help.

Please see the accepted answer for real details on how Access and JET get data.

Answer 6

I've written two commercial products that use an Access database, running from a network share, for typically up to 10 users. If you don't abuse it, there's really no problem; but as you can see many developers don't ever get there - and because of its low end nature, there are a lot of crappy hacks built on it. In the case of one product, I had to redesign the app because of all the problems described in detail by others; but after I cleaned it up, I never had a database integrity issue across hundreds of installations.

Its one big advantage is the single file database, which is easy to back up, restore, and copy to your laptop to dissect. Pretty much all the alternatives, including sqlite (although some won't admit it), require some form of DBA attention now and then.

In most cases, Access provides record locks, and file locks for some DDL (e.g. schema changes) by default.

But Microsoft is basically obsoleting it, and some of your colleagues will heap scorn upon you for using it.

(At this point I normally duck for cover and yell "INCOMING!!!".)