Discovering that your Access database won’t open — or opens with errors, missing data, or strange behavior — is one of the more stressful moments in database management. The good news is that Access corruption is usually recoverable, and there’s a clear sequence of steps to work through before you conclude that data is lost.
Stay calm and stop writing to the database
The first and most important rule: the moment you suspect corruption, stop all write activity. If multiple users are connected, have everyone close the database immediately. Every write operation against a corrupted file risks overwriting the sectors that contain your recoverable data. Treat it like a failing hard drive — the less you touch it, the better your odds.
Check whether it’s actually the database or something else
Before assuming corruption, rule out simpler causes. Verify the network share or file path is accessible. Check whether other users can open the file. Confirm the file hasn’t exceeded Access’s 2 GB size limit (check file size in Windows Explorer). Try opening the database on a different machine. Sometimes what looks like a corrupted database is a permissions issue, a broken network path, or a file that’s simply locked open by a crashed Access session.
Make a copy of the file before doing anything else
Before running any repair tools, copy the .accdb (or .mdb) file to a safe location. Repair attempts can sometimes make things worse, and you want a pristine copy of the damaged file to fall back on or hand off to a recovery specialist. Copy it to your local drive, not just another folder on the same network share.
Use Access’s built-in Compact and Repair tool
Access ships with a Compact and Repair utility designed specifically for this scenario. To run it:
Open Access without opening your database, go to Database Tools on the ribbon, and click Compact and Repair Database. Select your damaged file when prompted. If Access can open the file at all, you can also run Compact and Repair from within the open database via the same menu.
This tool rebuilds the internal structure of the database file, resolves index inconsistencies, and reclaims fragmented space. For minor corruption, this is often all you need. Run it on your copy, not your only copy.
Try decompiling if VBA is the problem
If the database opens but crashes on startup, freezes when certain forms load, or throws VBA errors that didn’t exist before, the corruption may be in the compiled VBA code rather than the data. Open Access using the command line with the /decompile switch:
“C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE” “C:\path\to\your.accdb” /decompile
This strips out the compiled p-code and forces Access to recompile from source on next open. After decompiling, open the database, go into the VBA editor, and run a full compile from the Debug menu. Then compact and repair again.
Import everything into a new blank database
If Compact and Repair doesn’t resolve the problem, the next technique is to create a brand new blank Access database and import objects from the damaged one. This works because the import process reads the object definitions rather than the raw file structure, often bypassing the corrupted sectors.
In your new blank database, go to External Data → New Data Source → From Database → Access, select the damaged file, and choose to import rather than link. Import tables first, then queries, then forms, reports, and modules. Import in stages — if one object fails, skip it and continue. You may lose a corrupted object but recover everything else.
Check for a .laccdb lock file
When Access opens a database, it creates a companion lock file with a .laccdb extension (or .ldb for older .mdb files) in the same folder. If Access crashed or was force-closed, this lock file sometimes persists and prevents the database from opening cleanly. Close all instances of Access, then look for a file with the same name as your database but with the .laccdb extension. If no one is actively in the database and this file exists, deleting it is safe and often resolves the “file already in use” error that can masquerade as corruption.
Restore from backup
If the repair steps above don’t recover your data, this is the moment you find out whether your backup discipline has been paying off. A nightly backup of the back-end .accdb file is the single most effective corruption recovery strategy — it reduces your worst-case data loss to one day. Restore the most recent clean backup and reconcile any transactions that occurred after that backup using paper records, email trails, or other sources if necessary.
If you don’t have a backup, that’s a process problem to solve before the next incident, not during this one.
Try third-party recovery tools
When built-in tools and the import method both fail, third-party Access recovery tools can sometimes extract data from files that Access itself can no longer read. Tools worth evaluating include DataNumen Access Repair, Stellar Repair for Access, and SysTools Access Recovery. These tools work by reading the raw binary structure of the .accdb file and reconstructing table data independently of the file’s internal indexes and system tables. Results vary depending on the nature and extent of the corruption, but they’re worth trying before declaring data lost.
Escalate to a specialist
If third-party tools don’t recover what you need and the data is business-critical, professional database recovery services exist. They work at the binary level and sometimes recover data that no software tool can. This is expensive and not always successful, but it’s the last legitimate option before accepting data loss.
Prevent the next incident
Corruption in Access most commonly results from network interruptions during a write operation, improper shutdowns, file sharing on unreliable network paths, and databases that have grown without regular compacting. Prevent recurrence by splitting your database if you haven’t already, storing the back-end on a reliable file server (not a mapped drive that drops), scheduling nightly automated backups, and running Compact and Repair on a regular cadence — monthly at minimum, weekly if the database is heavily used.
If your database is corrupting repeatedly, that’s a signal the architecture has outgrown what Access is designed to handle. It may be time to evaluate migrating the back-end tables to SQL Server or moving the application to Power Apps on Dataverse entirely.
Ready to talk through your options? Reach out to Anthony at AccessEvolved — email anthony@accessevolved.com or call 212-951-1010. No sales pitch, just a straight conversation about what makes sense for your situation.