Why Your Multi-User Access Database Keeps Corrupting
Microsoft Access databases corrupt because the database engine runs on each user's own PC and writes to a shared file over the network. Three causes account for nearly all corruption: an unsplit database, an unreliable network path to the shared folder, and too many simultaneous writers. Microsoft's own guidance is to keep an Access file-server arrangement to no more than 25 to 50 users where data changes frequently.
The usual declaration first: I rebuild Microsoft Access databases as web applications for a living, so the last fix in this post is the one I sell. The first three involve no work from anyone like me, and the first, splitting the database, genuinely works and costs an afternoon.
Corruption is a symptom, not a disease. Search the problem and you mostly find recovery tools, which sometimes rescue a file and never explain why it broke.
What "corruption" actually means in Microsoft Access
A corrupted Microsoft Access database is a file whose internal pages no longer agree with each other, usually because a write was interrupted before it finished. No server takes responsibility for finishing that write: each user's own copy of the engine writes into the shared file directly. Microsoft's documentation on Compact and Repair names that trigger: when a change to data is interrupted, for example by a loss of network service, "Access marks the database file as corrupted".
Not every flavour is equally frightening. Microsoft's same page notes that "often, this type of corruption results from a problem with a Visual Basic for Applications (VBA) module and does not pose a risk of data loss", while warning that it does risk "database design damage, such as lost VBA code or unusable forms". That is the mild end, cleared by rebuilding the front-end file. The severe end is a back-end file that opens with "Unrecognized database format", the engine reporting it cannot read the header it wrote.
The three causes, and the numbers behind them
Microsoft publishes the numbers that bound all of this.
| What Microsoft specifies | Number |
|---|---|
| Maximum concurrent users of one Access database | 255 |
| Recommended maximum where data is added and updated frequently | 25 to 50 |
Size of each user's entry in the .laccdb lock file |
64 bytes |
| Maximum size of the lock file | 16 kilobytes |
| Maximum size of one database file | 2GB, minus the space needed for system objects |
| Folder rights every shared user needs | Read, write, create and delete |
Verified against Microsoft's documentation on Access lock files and the Access specifications page on August 16, 2026.
Cause 1: the database is not split
An unsplit Microsoft Access database puts the tables, forms, queries, reports and VBA in one file that every user opens across the network. Every form redraw and every report becomes traffic against the file that holds your data, so any interrupted write is an interrupted write to your data.
Splitting separates the two. Microsoft's guidance on splitting an Access database describes the result: a back end holding the data tables, and a front end holding everything else, with each user working from a local copy. Microsoft states the reliability benefit plainly: "if a user encounters a problem and the database closes unexpectedly, any database file corruption is usually limited to the copy of the front-end database that the user had open." Because users reach the data only through linked tables, it adds, the back-end database file "is much less likely to become corrupted".
So splitting is step zero, and I will not hedge it: if your database is one file on a shared drive and more than one person uses it, split it this week. It moves the blast radius onto a disposable file you can replace from a master copy in minutes.
The honest limit is that splitting makes the back end safer rather than safe: it still sits on a file share, and still fails if the path to it fails. Each file also gets its own 2GB ceiling rather than sharing one, which eases the 2GB limit on every Access file without removing it. Splitting fixes the amplifier, not the design.
Cause 2: the network path to the shared drive
Every write travels a path: a PC, an adaptor, a switch, a cable or radio link, a server or NAS, a disk. Corruption arrives when that path breaks mid-sentence, and what I find is boringly consistent.
Wifi, sleep and power management. Laptops roam between access points, drop packets and renegotiate; a closing lid or a power-saving adaptor drops the connection mid-write. A wired connection with power saving disabled is the cheapest reliability upgrade an Access database can have, and often the whole fix for the one user who breaks the file every fortnight.
VPN and remote sessions. A tunnel renegotiating is the same event as a cable being pulled, and it happens far more often. That topic has its own post: what VPN, Remote Desktop and cloud storage each really cost.
Sync clients. Microsoft recommends against opening an Access database from OneDrive or a SharePoint document library, where the file is downloaded locally, uploaded again on save, and can end up as multiple copies. Dropbox and Google Drive are not named by Microsoft, but they reconcile whole files the same way, while Access writes continuously and expects exclusive control of its pages.
Folder rights. Microsoft's lock-file documentation is specific: a shared database "should be located in a folder where users have read, write, create, and delete privileges", even where the file itself is read-only for some of them. A user who cannot create the lock file cannot open the database properly; one who cannot delete it leaves it behind.
Antivirus and backup agents. Scanners and backup jobs that open the back-end file while people work are a recurring finding in my investigations rather than a documented Microsoft cause. Excluding the .accdb and .laccdb from real-time scanning, and running backups out of hours, costs nothing and removes a suspect.
None of that is exotic, which is the point: ordinary network life is enough to break the mechanism.
Cause 3: more concurrent writers than a file share can arbitrate
Microsoft's lock-file documentation explains that every database opened for shared use gets a .laccdb file in the same folder, or an .ldb for the older .mdb format. Each person who opens it gets an entry of 64 bytes, 32 for the computer name and 32 for the security name, which the engine uses "to prevent users from writing data to pages or records that other users have locked".
Because the engine supports at most 255 concurrent users, Microsoft notes, the lock file size "is never larger than 16 kilobytes". That is the hard ceiling; the soft one matters more, and Microsoft states it in the same place: where users frequently add and update data, it is a good idea to support "no more than 25 to 50 users", a tenth to a fifth of the maximum. Twenty users running reports is a different load from twenty users typing orders.
What goes wrong long before any ceiling is contention. Two people edit the same record and someone gets a write conflict, or Access reports that it couldn't lock a table currently in use by another user, naming the table, the user and the computer from the lock file. Those messages are not corruption, but they say the arbitration is working hard, and the harder it works the more often an interruption lands mid-operation.
Reducing concurrent writers is the least satisfying fix, because it is policy rather than engineering: stagger the data-entry shifts, move reporting to a copy, take casual browsers out of the live file. It buys stability at the price of flexibility.
If your team is already staggering shifts to keep a database alive, the free 24-hour Migration Blueprint maps what the database does and comes back with the scope, the timeline and a fixed quote for ending the file-sharing model, so the comparison is against a number rather than a guess.
What Access corruption is not
Pages on this topic are usually wrong by omission, so here is what gets blamed and is not the cause.
It is not a corrupted lock file. Microsoft is unambiguous: "The state of the information in the lock file has no bearing on the state of the database. If a lock file becomes corrupted, everything in the database should still work correctly." A stale .laccdb left when nobody is in the database is safe to delete, and deleting it fixes nothing else.
It is not a lock conflict. Write conflicts and lock messages are the locking system working: a capacity signal, not damage.
It is not the 2GB limit, though the two look identical from outside. A file that cannot grow fails in a corruption shape rather than a quota shape, which is why a database near the 2GB ceiling reports damage rather than fullness. Check the file size first.
It is not Access being old. An unsupported copy of Access corrupts files at the same rate as a supported one. The version lifecycle is a real issue, and a separate one.
It is not usually one bad record. By the time Access refuses to open a file, the damage is structural: a header, an index or a page allocation.
It is not permanently fixed by a recovery tool. Recovery tools recover files. Running one changes nothing about the split, the network path or the number of writers, which is why the same database comes back to the same tool.
What to do when a file has just corrupted
Five steps, and the order matters.
Get everyone out, and confirm it. Microsoft notes that the lock file is deleted when the last user closes a shared database, unless a user lacks delete rights or the database is already marked as corrupted. A .laccdb still sitting there afterwards is itself information.
Copy the file before you touch it. Microsoft's reason for making a backup first is worth quoting exactly: "During the repair process, Access may truncate some data from tables that are damaged."
Run Compact and Repair on the copy. Database Tools, then Compact and Repair Database. It rebuilds the file and resolves most single-event damage.
If that fails, import into a fresh database. Create a new empty file and import the objects from the damaged one, which leaves behind any damage living in a single object.
Check what your last good backup actually is. Damage often surfaces days after the write that caused it, so a nightly copy of an already damaged file is not a backup. Keep dated copies and open one occasionally to prove it reads.
What each fix actually buys you
| Fix | Effort | What it buys | What it leaves in place |
|---|---|---|---|
| Split the database | An afternoon | Corruption usually confined to one user's front end; less traffic to the data file | A back end still on a file share; causes 2 and 3 untouched |
| Harden the network path | Hours to days | Removes the commonest interruption trigger; wired users rarely corrupt files | Remote and home users still exposed; nothing about concurrency |
| Reduce concurrent writers | A policy, not a project | Fewer conflicts and fewer interrupted writes | A ceiling on how the business is allowed to work |
| Move the back end to SQL Server | Weeks, with care | Writes become server transactions instead of file writes; the mechanism ends | Access on every desktop; the front end and its own corruption |
| Rebuild as a web application | A real project | No shared file, no lock file, no per-machine Access licence | The old database, once you cut over |
The first three rows delay the problem; the last two end it. Splitting and a wired network will carry a well-behaved five-user database for years, and I have told plenty of people exactly that.
When the three fixes stop being enough
The moment the arithmetic tips is recognisable from outside. Somebody has become the person who runs the repair. A message goes round asking everyone to get out of the database. A member of staff keeps a spreadsheet because they do not trust the database on a Monday. At that point the cost has stopped being technical and started being salary.
The route out is to stop sharing a file at all, so that the engine sits where the data lives and users get a client holding no data of its own: a SQL Server back end under your existing forms, or a web application built from your Access database. The second is what I sell, so weigh it against the last two rows above.
If your database corrupted this week
Do the five steps above, in order, starting with the copy. Then answer three questions honestly: is it split, is every user wired with the folder rights Microsoft specifies, and how many people write to it at once.
If the answers say the file-sharing model itself is the problem, send me a short description of the database. The Migration Blueprint below comes back within 24 hours with the scope, the timeline and an exact fixed quote. It is free, and there is no call.