1. Identify what is blocking the rebuild
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.
Access recovery
Compact and Repair Is Not Working on Your Access Database
It fails, hangs, throws error 3045, or the file came back worse. We diagnose the cause and recover with a written fixed-scope quote—typically from $1,200—working only on copies.
Compact failed and the file is now worse? Call +1 385 386 3860 and stop running further repair passes.
Call us at +1 (385) 386-3860
- ApproachObject-level rebuild, not another compact
- AssessmentFree, and usually same business day
- HandlingWe work on copies, never your original
Quick answer: When Compact and Repair fails, hangs, or leaves the file worse, stop re-running it on your only copy. Excel Access Expert provides fixed-scope recovery: free assessment, written quote typically from $1,200, object-level rebuild on copies. Common causes are a lock (user, antivirus, or cloud sync), folder permissions, a near–2 GB file, or a damaged object inside. Symptom rows below help triage; if Compact already rewrote the file, send the earliest untouched copy. Recurring network damage often ends with Access to SQL Server migration; for keep-or-move after recovery, use our MS Access consultant.
Access specialists since 2011 (15+ years). Applies to Access 2010 through Microsoft 365, ACCDB and MDB. Last updated October 22, 2026.
Most people treat Compact and Repair as a safe tidy-up. It is closer to a rebuild: Access creates a brand-new file, copies every object it can read into it, refreshes table statistics and indexes, and then replaces your original with the new one. That explains both the failures and the damage. 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 could not read, you can end up with less than you started with.
Quick Diagnosis: Error Message to Likely Cause
Start here. Match what you see to the most likely cause, then jump to the detailed fix below.
| What you see | Most likely cause | First move |
|---|---|---|
| 'Could not use [file]; file already in use' (error 3045) | Another session, a stray msaccess.exe, antivirus or a sync client holds the file. | Close every session, end msaccess.exe in Task Manager, retry on a local copy outside sync folders. |
| Compact and Repair is greyed out | File is read-only, blocked by Windows, or no database is open. | Check file Properties (Read-only, Unblock), copy to a local folder with full rights, reopen. |
| 'Cannot open database... may not be a database that your application recognizes' (error 3049) | Damaged file header or system tables. | Stop compacting. Import objects into a new database from a copy. |
| 'The query cannot be completed... size of a database (2 GB)' | File near the 2 GB limit, or no room for the rebuilt copy or TEMP space. | Free disk space, trim data on a copy, plan a move to SQL Server. |
| Stops partway, or 'Disk or network error' (error 3043) | Permissions, disk space, or a dropped network or VPN connection. | Compact a local copy in a folder where you have full control. |
| Access shows 'Not Responding' | Large file on a slow drive or network, or a hang on a damaged object. | Watch disk activity before ending it. Never restart it on your only copy. |
| 'Repaired' but tables, forms or queries are missing | Access dropped objects it could not read (see MSysCompactErrors). | Stop. Restore from backup or import from the untouched original. |
| Crashes when a form opens, or compact never completes | Damaged compiled VBA project. | Run /decompile on a copy, recompile, then compact. |
| File is still huge after compacting | Real data: attachments, images, OLE objects or large text fields. | Audit the largest tables. Consider SQL Server for the data. |
Why Compact and Repair Fails: 9 Causes and the Fix for Each
1. Someone or something still has the database open
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. The VBA user-roster snippet further down lists exactly who is connected.
2. Antivirus or cloud sync is locking the file
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.
3. You don't have permission to create and delete files in the folder
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.
4. The file is read-only or blocked by Windows
A file with the Read-only attribute, or one downloaded or emailed that Windows has flagged as blocked, can open with limited rights, and the Compact and Repair button may be greyed out or fail. What to do: right-click the file, choose Properties, clear Read-only, and select Unblock if it appears, then reopen from a local, trusted folder.
5. Not enough free disk space
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 is 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.
6. The file is at or near the 2 GB limit
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.
7. It hits an object it cannot read
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 for 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.
8. The compiled VBA project is damaged
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.
9. It's running over a network or VPN
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.
What to Do Instead, in Order
Step 1: Copy the file first and work only on the copy. This single step prevents most disasters we are called about. Copy it with nobody in the file, so the copy is consistent.
Step 2: Get everyone out, end any stray msaccess.exe processes, and confirm you genuinely have exclusive access (no .laccdb or .ldb lock file beside the database).
Step 3: Move the copy to a local drive outside OneDrive, Dropbox or SharePoint sync folders, and check free space is at least the size of the database on both that drive and the Windows TEMP drive.
Step 4: Try Compact and Repair once on the copy (Database Tools > Compact and Repair Database). If it completes, check for MSysCompactErrors and compare object counts against the original.
Step 5: If it fails, create a new blank database and import into it: External Data > New Data Source > From Database > Access. Import tables first, then queries, forms, reports, macros and modules. If one object refuses to come across, you have found the damage.
Step 6: Before importing, click Options in the import dialog and tick Relationships so table links come across. Afterward, re-set Current Database options (startup form, ribbon, Compact on Close) and re-check VBA references, because those are not imported.
Step 7: If the symptoms point at code rather than data, run a decompile pass on the copy, then recompile and compact.
Step 8: If none of that completes, stop. The structure needs proper recovery, and further passes can shrink what is recoverable.
VBA and Command-Line Tools for Safe Compacting
These are the same checks we run by hand: lock file, free space on the target and TEMP drives, compact into a new file, then verify before anyone swaps anything. Use them from a separate maintenance database or the command line, never from the database you are compacting, and always test on a copy first.
Option Compare Database
Option Explicit
' Paste into a STANDARD module in a separate "Maintenance.accdb".
' Access cannot compact the file it is currently running from.
' Run from the Immediate window: ?SafeCompact("C:\Data\Sales_BE.accdb")
' The original is never touched. You get a compacted COPY to verify first.
Public Function SafeCompact(ByVal sourcePath As String) As Boolean
Dim fso As Object
Dim ext As String, lockPath As String, outPath As String
Dim sourceSize As Double
Dim srcTables As Long, srcQueries As Long, srcErr As Boolean
Dim outTables As Long, outQueries As Long, outErr As Boolean
On Error GoTo Fail
Set fso = CreateObject("Scripting.FileSystemObject")
If Not fso.FileExists(sourcePath) Then
Debug.Print "File not found: " & sourcePath
Exit Function
End If
' 1. Is anyone still in the file? (a lock file means a session is open or crashed)
ext = LCase$(fso.GetExtensionName(sourcePath))
lockPath = Left$(sourcePath, Len(sourcePath) - Len(ext)) & _
IIf(ext = "mdb" Or ext = "mde", "ldb", "laccdb")
If fso.FileExists(lockPath) Then
Debug.Print "Lock file found, someone may still be in the database: " & lockPath
Exit Function
End If
' 2. Enough free space for a second copy (target drive AND Windows TEMP drive)?
sourceSize = fso.GetFile(sourcePath).Size
If FreeBytes(fso, sourcePath) < sourceSize * 2 Then
Debug.Print "Not enough free space beside the database. Free at least 2x its size."
Exit Function
End If
If FreeBytes(fso, Environ$("TEMP")) < sourceSize * 1.5 Then
Debug.Print "Not enough free space on the Windows TEMP drive."
Exit Function
End If
' 3. Compact into a NEW file. The original stays exactly as it was.
outPath = fso.GetParentFolderName(sourcePath) & "\" & _
fso.GetBaseName(sourcePath) & "_compacted_" & _
Format$(Now, "yyyymmdd_hhnn") & "." & ext
If Not Application.CompactRepair(sourcePath, outPath, True) Then
Debug.Print "CompactRepair reported failure. Check for a log file beside: " & outPath
Exit Function
End If
' 4. Verify: object counts must match and MSysCompactErrors must not exist.
Inventory sourcePath, srcTables, srcQueries, srcErr
Inventory outPath, outTables, outQueries, outErr
Debug.Print "Source : " & srcTables & " tables, " & srcQueries & " queries"
Debug.Print "Compacted : " & outTables & " tables, " & outQueries & " queries"
Debug.Print "Size : " & Format$(sourceSize / 1048576, "0.0") & " MB -> " & _
Format$(fso.GetFile(outPath).Size / 1048576, "0.0") & " MB"
If outErr Then
Debug.Print "MSysCompactErrors exists: Access dropped something. Do NOT swap files."
ElseIf srcTables <> outTables Or srcQueries <> outQueries Then
Debug.Print "Object counts differ. Do NOT swap files."
Else
Debug.Print "Looks clean. Test the compacted copy, then swap the files yourself."
SafeCompact = True
End If
Exit Function
Fail:
Debug.Print "Error " & Err.Number & ": " & Err.Description
End Function
Private Function FreeBytes(fso As Object, ByVal anyPath As String) As Double
FreeBytes = fso.GetDrive(fso.GetDriveName(fso.GetAbsolutePathName(anyPath))).AvailableSpace
End Function
Private Sub Inventory(ByVal dbPath As String, ByRef tableCount As Long, _
ByRef queryCount As Long, ByRef hasErrorTable As Boolean)
Dim db As DAO.Database, td As DAO.TableDef, qd As DAO.QueryDef
Set db = DBEngine.OpenDatabase(dbPath, False, True) ' read-only
For Each td In db.TableDefs
If td.Name = "MSysCompactErrors" Then
hasErrorTable = True
ElseIf (td.Attributes And dbSystemObject) = 0 Then
tableCount = tableCount + 1
End If
Next td
For Each qd In db.QueryDefs
If Left$(qd.Name, 1) <> "~" Then queryCount = queryCount + 1
Next qd
db.Close
End Sub' Lists every computer and login currently connected to a shared database.
' Run from the Immediate window: ShowConnectedUsers "\\SERVER\Share\Sales_BE.accdb"
' If the provider is not found, change 12.0 to 16.0.
Public Sub ShowConnectedUsers(ByVal dbPath As String)
Const adSchemaProviderSpecific As Long = -1
Dim cn As Object, rs As Object
Set cn = CreateObject("ADODB.Connection")
cn.Open "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & dbPath
Set rs = cn.OpenSchema(adSchemaProviderSpecific, , _
"{947bb102-5d43-11d1-bdbf-00c04fb92675}")
Do While Not rs.EOF
Debug.Print Trim$(rs.Fields("COMPUTER_NAME") & "") & " | " & _
Trim$(rs.Fields("LOGIN_NAME") & "") & " | connected: " & _
rs.Fields("CONNECTED")
rs.MoveNext
Loop
rs.Close
cn.Close
End Sub:: Compact from the command line (no one else may have the file open)
"C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE" "C:\Data\Sales_BE.accdb" /compact "C:\Data\Sales_BE_compacted.accdb"
:: Decompile a COPY of a front end with damaged compiled VBA
"C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE" "C:\Data\Sales_FE_copy.accdb" /decompile
:: Then open the copy, Debug > Compile, save, and compact it.
:: (Office install paths vary: check where MSACCESS.EXE lives on your PC.)Test every script on a copy of your database first. If a verification line says "Do NOT swap files", stop and send us the file.
How We Handle It
Our sequence
Find the damaged object, secure the data, then remove the cause.
2. Secure the data first
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.
3. Rebuild the broken objects
Damaged forms, queries, reports and code are rebuilt in a clean file instead of being copied forward with the fault still in them.
4. Address size and growth
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.
5. Remove the underlying cause
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.
When to Stop and Call an Access Expert
MSysCompactErrors exists, or tables, forms or queries went missing after a repair.
Error 3049 or 'unrecognized database format' appears, or the file will not open at all.
One specific table or object will not import into a new database.
The file is near 2 GB, or locks and compacts have become a weekly routine.
You have no verified backup and the data runs the business.
You have already run Compact and Repair several times and the file is getting worse.
If one of those matches, stop touching the original and send us a copy. For deeper damage, see Access database repair, or if the file will not open at all, unrecognized database format recovery.
When Compacting Is the Wrong Conversation
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. A split database keeps the data (back end) on the server and gives each user a local copy of the forms and reports (front end), which cuts both lock errors and growth. If the file is repeatedly near 2 GB or the team is constantly locked out, 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.
What It Costs
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.
FAQ
Frequently Asked Questions
Find answers to common questions about our services
Compact and Repair usually fails because another user or process still has the file open (including antivirus or a cloud-sync client), you lack permission to create and delete files in the folder, the file is read-only or blocked by Windows, the drive has too little free space, the file is near the 2 GB limit, the compiled VBA is damaged, or an object inside the file cannot be read. Each cause has a different fix, so identify which one applies before running it again.
It means Access cannot get exclusive access to the file. The usual causes are another user or a leftover msaccess.exe process holding it open, antivirus real-time scanning locking the file, or a cloud-sync client such as OneDrive or Dropbox touching it mid-rebuild. Close every session, end stray msaccess.exe processes in Task Manager, copy the file to a local folder outside any sync location, and ask your IT team about excluding msaccess.exe from real-time scanning.
The button is commonly unavailable when no database is open, or when the file is open read-only. Check the file's Properties for a Read-only attribute or an Unblock option (Windows blocks some downloaded or emailed files), confirm you have write permission to the folder, and try again on a local copy. If you only have a runtime version of Access with no ribbon, use the VBA or command-line methods on this page instead.
Yes. Compact and Repair rebuilds the file into a new one and then replaces your original. If it cannot read a table, record or object, it can leave that item out, and the reduced file becomes your database. The other risk is interruption during the final file swap. Always run it on a copy, and check for the MSysCompactErrors table afterward to see what, if anything, was dropped.
In order: copy the file and work only on the copy, close every other session so you have exclusive access, make sure free disk space is at least the size of the file (check the Windows TEMP drive too), and move the copy to a local drive if it is on a network share or sync folder. Then import all objects into a brand-new blank database instead of compacting the damaged one. If the VBA project is the problem, a decompile pass often clears it. If none of that works, the file needs proper recovery.
Access has a hard 2 GB limit per file, and compacting needs room to write a rebuilt copy plus temporary working space. A file close to the limit, or a drive (including the one holding your Windows TEMP folder) without enough free space, can trigger this error. If you are regularly near 2 GB, compacting is treating a symptom and the data should move to SQL Server with Access kept as the front end.
Large files, slow drives and network shares can make the rebuild take a long time, and Access looks frozen while it works. Check disk activity before ending the process. If nothing has moved for a long time, end it, leave the original untouched, and look for a leftover temporary database (often named like db1.accdb) in the same folder. Never keep re-running it on your only copy. Compacting over a network or VPN is much slower and riskier than compacting a local copy.
MSysCompactErrors is a system table Access creates when Compact and Repair meets something it cannot repair. It lists the error and the object or table involved. To see it, turn on Show System Objects in the Navigation Options. If it exists, treat the compacted file as incomplete, compare it with your last backup, and do not let it replace your only copy.
No. Compact and Repair needs exclusive access, so everyone must close the database first. If you cannot tell who is still in the file, look for a .laccdb (ACCDB) or .ldb (MDB) lock file next to the database, check Task Manager for stray msaccess.exe processes, or use the VBA user-roster snippet on this page to list connected computers.
Access reclaims space only when it compacts, and everyday work such as temporary objects, deleted records and queries that write intermediate results inflates the file continuously. If the file stays large after compacting, the space is real data: look for attachment fields, embedded images or OLE objects, and very large text columns. Rapid regrowth plus slowdowns usually points to an unsplit database or a front end running from a network share.
For a single-user database on a local drive, it is a reasonable convenience. For a shared database, we generally recommend leaving it off and compacting deliberately, on a copy, after a verified backup. Automatic compacting on a file several people open, or on a network share, is a common source of lock errors and lost work.
Yes. From VBA, Application.CompactRepair compacts one closed file into a new destination file, so run it from a separate maintenance database, not the one being compacted. From the command line, use msaccess.exe with the /compact switch and a target file name. This page includes examples of both that compact into a new copy and leave your original untouched.
The assessment is free, and you get a fixed price in writing before any billable work begins. We tell you whether this is a maintenance issue, a structural one, or a sign the data has outgrown Access. 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.
Compacting still failing?
Send us the error, where it stops, and the file size. We will tell you what is actually wrong before you commit to anything.
1
15-min audit
→
2
Fixed-scope quote
→
3
Deliver outcome
15+Years Experience
FixedScope Quotes
2011Established
Prefer to talk? Call us at +1 385 386 3860