Access maintenance
Compact failed and the file is now worse? Call +1 385 386 3860 and stop running further repair passes.
Compact and Repair usually fails because something still has the file open, the folder or disk won't allow the rebuild, the file is near the 2 GB limit, or an object inside it is damaged. Antivirus and cloud-sync software are common hidden culprits. The fix depends on which cause it is, and re-running it on your only copy is the one thing that can make matters worse.
Most people treat Compact and Repair as a safe tidy-up. It isn't. It builds a brand-new file, copies every object it can read into it, and then replaces your original with the new one. Once you know that, the failures make sense: it needs exclusive access, permission to create and delete files in the folder, free disk space, and readable objects. Miss any of those and it stops. And when it 'succeeds' by leaving out what it couldn't read, you can end up with less than you started with.
Last updated September 28, 2026.
The rebuild needs exclusive access. A colleague with the file open, a locked machine still running Access, an orphaned msaccess.exe process in Task Manager, or a leftover lock file (.laccdb for ACCDB, .ldb for MDB) after a crash is enough to block it. The message rarely says who or what is holding the file. What to do: have everyone close the database, end any stray msaccess.exe processes, and delete a leftover lock file only after confirming nobody is in the database.
If you see 'Could not use; file already in use' (error 3045) and nobody else is in the file, suspect software. Real-time antivirus scanning and sync clients such as OneDrive, Dropbox and SharePoint can grab the file while Access is rebuilding it. What to do: copy the database to a local folder outside any sync location, retry there, and ask your IT team about excluding msaccess.exe from real-time scanning. Don't change security settings without IT's approval.
Compact and Repair writes a new file and then swaps it for the original, so it needs rights to create and delete files in that folder, not just edit the database. Read-only folders and restricted network shares stop it partway. What to do: work on a copy in a folder where you have full control.
A second copy of the database has to be written before the swap. If the drive can't hold it, the operation fails partway. Also check the drive that holds your Windows TEMP folder, which Access uses for working space. This catches people out on nearly full server volumes and laptops with small SSDs, and it's worth checking before assuming the file is damaged. What to do: free up space at least equal to the database size, with room to spare.
Access allows 2 GB per file. Near that ceiling there isn't enough headroom to write the rebuilt copy, so compacting fails, and the database usually starts misbehaving in other ways too. What to do: trim or archive data on a copy and retry, then plan the real fix. At this point compacting is the wrong conversation: the data needs to move.
If a single table, query or form is damaged, the copy either stops at that object or leaves it out. When Access can't repair something, it may create a system table called MSysCompactErrors listing what it couldn't handle. To see it, turn on 'Show System Objects' in Navigation Options. What to do: check that table after any repair, and never let a reduced file overwrite your only copy. Import the objects into a fresh database and see which one refuses to come across.
Corruption in compiled VBA produces odd behavior: crashes when a form opens, errors that move around, compacting that won't complete, all while the tables are healthy. What to do: on a copy, run Access with the /decompile switch, then recompile and compact. This often resolves it without touching your data.
Compacting a file across a network share or VPN is slow and fragile, because a dropped connection mid-rebuild can leave a half-written file. What to do: copy the database to a local drive, compact there, then put it back. If the file keeps misbehaving on the network, see Access corruption over LAN, Wi-Fi and VPN.
The wording varies by Access version, but these are the ones we see most.
Access can't get exclusive access. Another user or process has the file, or antivirus or a sync client is locking it. Close every session, end stray msaccess.exe processes, and retry on a local copy.
The rebuild ran out of headroom, either because the file is near the 2 GB limit or the drive (or TEMP folder) is short on space. Free space first, then look at reducing data or moving to SQL Server.
Sometimes it's just a big file on a slow drive or network. Check disk activity before ending the process, and never keep restarting it on your only copy.
Access may have dropped what it couldn't read. Check for the MSysCompactErrors table, compare against your last backup, and stop before anything else overwrites the file.
Step 1: Copy the file first and work only on the copy. This single step prevents most disasters we are called about.
Step 2: Get everyone out, end any stray msaccess.exe processes, and confirm you genuinely have exclusive access.
Step 3: Move the copy to a local drive outside OneDrive, Dropbox or SharePoint sync folders, and check free disk space is at least the size of the database.
Step 4: Create a new blank database and import the objects into it, rather than compacting the damaged one. If a specific object fails to import, you have found the damage.
Step 5: If the symptoms point at code rather than data, run a decompile pass on the copy, then recompile.
Step 6: If none of that completes, stop. The structure needs proper recovery, and further passes can shrink what is recoverable.
Find the damaged object, secure the data, then remove the cause.
Exclusive access, antivirus or sync interference, permissions, disk space, a specific unreadable object, or the VBA project. Each has a different fix, and guessing is what makes files worse.
We pull the tables out into a clean database before doing anything that rewrites the original, so the records are safe regardless of what follows.
Damaged forms, queries, reports and code are rebuilt in a clean file instead of being copied forward with the fault still in them.
If the file keeps inflating, we find what is inflating it, such as temporary objects, oversized attachments or queries writing intermediate results, instead of scheduling more compacting.
Split the database properly, move front ends to each desktop, and say plainly when the data has outgrown Access.
Work is performed on backup copies only. Secure handling, nothing shared with third parties.
Compacting is maintenance. If you need it weekly to keep the database usable, the real problem is elsewhere: an unsplit database that several people open directly, a front end running from a network share, or data volumes Access was never meant to carry. If the file is repeatedly near 2 GB or the team is constantly locked out, the fix is to move the data to SQL Server and keep the Access screens your staff already know. See Access to SQL Server migration. If it is slowness rather than size, start with optimizing the database. For ongoing help, see our MS Access support service.
Fixed-scope project estimates based on the business value we deliver. Projects typically start at $1,200 - smaller fixes can be less, larger systems more.
The assessment is free and the figure is in writing before any billable work starts. If your answer is simply free disk space or getting one person out of the file, we will tell you that. For corruption that has gone further, see Access database repair, or if the file will not open at all, unrecognized database format recovery.
FAQ
Find answers to common questions about our services
Send us the error, where it stops, and the file size. We will tell you what is actually wrong before you commit to anything.
Prefer to talk? Call us at +1 385 386 3860