If you have managed an Access database for any length of time, you have dealt with corruption. Maybe it was a form that stopped opening. Maybe it was a table that returned garbage data. Maybe the whole file just refused to open one morning.
Database corruption is not a rare event in Access. It is a regular part of the Access experience, and understanding why it happens is the first step toward deciding what to do about it.
How Access Stores Data
To understand corruption, you need to understand how Access works at a fundamental level.
Access uses a file-based database engine — originally Jet, now ACE.
Your entire database — every table, query, form, report, macro, and VBA
module — lives in a single .accdb file (or
.mdb for older versions). There is no database server
managing access to this file. When you open the database, your copy of
Access reads and writes directly to that file.
This is fundamentally different from how SQL Server, MySQL, or PostgreSQL work. Those databases have a server process that sits between users and the data files. The server controls all reads and writes, manages transactions, and ensures that if something goes wrong mid-write, the data can be recovered.
Access has no such protection. It writes directly to the file, and if anything interrupts that write, the file is damaged.
The Most Common Causes of Corruption
Network Interruptions
This is the number one cause. When Access writes to a database file on a shared network drive, the data travels over your LAN using the SMB protocol. If that connection is interrupted mid-write — a network switch hiccup, a cable that gets bumped, Wi-Fi that drops for half a second — the file is left in an inconsistent state.
The write operation was partially completed. Some bytes were written, others were not. The internal page structure of the file no longer makes sense.
Workstation Crashes
If a user’s computer crashes, freezes, or loses power while Access has the database open, any pending writes are lost. Even if the user was not actively saving at that moment, Access may have been writing lock information, updating indexes, or flushing cached data.
Windows updates that restart machines without warning are a particularly common trigger. A user steps away from their desk, Windows installs updates and reboots, and the Access database was still open.
Multiple Users and File Locking Conflicts
Access uses a lock file (.ldb or .laccdb)
to coordinate multi-user access. This system works for a few users but
becomes increasingly fragile as you add more.
When two users try to write to the same data page simultaneously, Access relies on the operating system’s file locking to prevent conflicts. But file locking over a network is not perfectly reliable. Race conditions can occur where both users believe they have exclusive access to the same page, and both write to it.
The result is overlapping writes that damage the page structure.
Oversized Databases
Access has a 2GB file size limit. As the database approaches this limit, Access has less room to manage its internal structures. Compact and Repair operations need temporary space. Index updates need room to work.
When the database is near capacity, even normal operations can fail in ways that corrupt the file. And Access does not warn you as you approach the limit — it just starts failing.
Improper Shutdowns
Closing Access by killing the process in Task Manager, pulling the plug on the machine, or force-closing a Remote Desktop session can all leave the database in a corrupted state. Access needs to close files properly to flush writes and release locks.
What Compact and Repair Actually Does
Microsoft’s recommended solution is the Compact and Repair utility. Here is what it actually does:
- Creates a new, empty database file
- Copies all objects from the damaged file to the new one
- Rebuilds the internal page structure and indexes
- Replaces the old file with the new one
This process can fix many forms of corruption — damaged indexes, orphaned pages, inconsistent internal pointers. But it has significant limitations:
- It cannot recover lost data. If a write was interrupted and data was partially written, that data is gone. Compact and Repair can fix the structure, but it cannot reconstruct data that was never fully saved.
- It can make things worse. If the corruption is severe enough, Compact and Repair can fail partway through, leaving you with two damaged files instead of one.
- It requires exclusive access. All users must close the database before you can run it. In a busy office, this means scheduling downtime.
- It is reactive, not preventive. Running Compact and Repair weekly is treating the symptom, not the cause.
How to Reduce Corruption Risk
You cannot eliminate corruption risk entirely while using Access as your database engine, but you can reduce it significantly:
Split the database. Separate your tables (back-end) from your forms, reports, and code (front-end). Each user gets their own copy of the front-end file, and they all link to a shared back-end. This way, if a user’s front-end corrupts, the data is unaffected. You just give them a fresh copy of the front-end.
Use wired network connections. Wi-Fi drops are a major corruption trigger. If users must access the database over a network, wired Ethernet is significantly more reliable than wireless.
Disable Windows auto-restart for updates. Configure Group Policy to prevent Windows from restarting machines while Access is running. This eliminates one of the most common causes of unexpected shutdowns.
Back up aggressively. Back up the database file multiple times per day — not just nightly. When corruption happens, you want to lose hours of data at most, not days.
Keep the file size under control. Archive old records to a separate database. Remove OLE Object fields if possible — they consume enormous amounts of space. Run Compact and Repair regularly to reclaim space from deleted records.
Set a maximum user count. If you have more than 10 concurrent users, you are in the danger zone. The more users, the more likely a locking conflict or network collision will cause corruption.
When Prevention Is Not Enough
All of these steps reduce risk, but they do not eliminate it. The fundamental problem is architectural: Access writes directly to a file over a network, with no server process to manage transactions or recover from failures.
Server-based databases solve this problem completely. SQL Server, MySQL, MariaDB, and PostgreSQL all use write-ahead logging (WAL) — every change is first written to a transaction log before being applied to the data files. If anything goes wrong, the server replays the log to bring the data back to a consistent state.
This is not a nice-to-have feature. It is the fundamental difference between a file-based database and a server-based database.
If you are running Compact and Repair regularly, restoring from backups more than occasionally, or losing data to corruption, you have outgrown what Access can safely provide. The question is not whether to move to a server-based database — it is which one, and how to get there.