MS Access Error Troubleshooting: Complete Guide to Fixing Crashes, Corruption & Database Errors

Why MS Access databases break

Microsoft Access errors come from four root-cause buckets. Every error we have diagnosed in 15 years of production work falls into one of these categories. Knowing which bucket your error belongs to determines the correct fix — and prevents you from running Compact & Repair in a loop while the real cause goes untouched.

• →File-level corruption: Caused by an improper shutdown, a force-kill during a write, editing the live back-end directly, or a network interruption mid-transaction. Compact & Repair addresses minor cases. Severe corruption requires a safe-copy import.
• →Environmental mismatch: Wrong Office bitness (32 vs 64-bit), different Office build channels across user machines, mapped drive letters that vary by session, NTFS permission gaps that prevent .laccdb creation. Looks like database corruption but the file is fine.
• →Structural debt: Un-split monolithic files, orphaned queries, VBA that assumes yesterday's schema, no error handling in procedures. Makes random errors look random when they are entirely predictable under load.
• →External dependencies: ODBC connections to SQL Server that drop on VPN, broken linked table paths after a server move, missing COM references after an Office update, third-party OCX controls that were not updated when Office was upgraded.

Quick triage — the first 10 minutes

Before touching anything in production, run these four checks in order. They take under ten minutes and will tell you which section of this guide to go to — preventing you from wasting hours on the wrong fix.

1. 1Screenshot the full error dialog. Note the exact error number and full text. For ODBC errors, the number alone (3146) is not enough — the inner driver message is what matters. If you have VBA access, add a temporary MsgBox Err.Number & " - " & Err.Description to your error handler and log DBEngine.Errors for ODBC failures.
2. 2Check whether the .laccdb file exists beside the back-end. If it does not appear when a user opens the front-end, ACE cannot write the lock file — a permissions problem, not a database problem. If it shows unexpected machine names, an orphaned session is holding a lock. Jump to multi-user locks.
3. 3Run Debug → Compile VBAProject in the VBA IDE (Alt+F11). A red-highlighted line means a compile error is masquerading as a runtime error. Fix compile errors first — they produce runtime faults on the first execution of that code path and look exactly like database bugs.
4. 4Confirm all users are on the same Office build channel. File → Account → About in any Office app. Mixed channels (Current, Monthly Enterprise, Semi-Annual) mean different ACE engine builds on different machines. This is the single most common cause of "works on my machine, fails on theirs" tickets we receive from US businesses.

Fix: MS Access database not opening

"Database not opening" covers several distinct error messages that each point to a different cause. Match your error to the right fix:

Read the .laccdb lock file to find who is blocking access

The .laccdb file sits beside your back-end .accdb and lists every active session as a plain-text machine name and username pair. You can open it in Notepad or read it with PowerShell. If it does not exist when users are connected, ACE cannot create it — fix NTFS permissions on the folder (the user account needs Read, Write, and Create on the folder, not just the file).

REM ── Read the .laccdb lock file to find who holds the lock ──
REM ── Rename the file to .txt or open directly in Notepad ──
REM ── It is a plain-text file listing active sessions: ──

REM Example .laccdb content:
REM   DESKTOP-ABC123        jsmith
REM   LAPTOP-FINANCE01      mbrown
REM
REM Format: MachineName [tab] UserName
REM One row per active session.
REM If the file does not exist at all — no users are connected,
REM or ACE cannot write it (NTFS permission gap on the folder).

REM ── Check whether .laccdb exists using PowerShell ──
Test-Path "\serversharecompany_be.laccdb"

REM ── List all active sessions ──
Get-Content "\serversharecompany_be.laccdb"

Relink all tables to a new back-end path (VBA)

When the back-end .accdb moves — different server, different share name, or a drive-letter-to-UNC conversion — every linked table in the front-end breaks. The function below relinks all of them in one pass. Always use UNC paths (\\server\share\db.accdb) — mapped drive letters vary by user session and are the single most common cause of error 3044.

' ── Relink all Access linked tables to a new UNC back-end path ──
' Run this from a standard VBA module in the front-end .accdb
' Requires: DAO reference (Microsoft Office XX.X Access database engine)

Public Sub RelinkAllTables(ByVal newBackendPath As String)
    ' newBackendPath must be a full UNC path, e.g.:
    '   "\\server\share\company_be.accdb"
    ' Drive letters like "Z:..." will break for other users — always use UNC.

    On Error GoTo EH
    Dim db  As DAO.Database
    Dim tdf As DAO.TableDef

    Set db = CurrentDb

    For Each tdf In db.TableDefs
        ' Only relink tables that are currently linked (have a Connect string)
        If Len(tdf.Connect) > 0 And Left$(tdf.Connect, 10) = ";DATABASE=" Then
            tdf.Connect = ";DATABASE=" & newBackendPath
            tdf.RefreshLink   ' Apply the new path immediately
            Debug.Print "Relinked: " & tdf.Name
        End If
    Next tdf

    MsgBox "All linked tables relinked to:" & vbCrLf & newBackendPath, _
           vbInformation, "Relink Complete"
    Exit Sub
EH:
    MsgBox "Relink failed on table [" & tdf.Name & "]." & vbCrLf & _
           "Error " & Err.Number & ": " & Err.Description, _
           vbCritical, "Relink Error"
End Sub

' ── Usage — paste into Immediate Window (Ctrl+G) and run: ──
' RelinkAllTables "\serversharecompany_be.accdb"

Fix: crashes & multi-user lock storms

Multi-user crashes and lock storms are structural problems, not random events. They happen predictably under load and follow the same root cause: multiple users competing for page-level or table-level locks in an un-split database.

The un-split database problem

A monolithic (un-split) .accdb is a single file that holds both the interface (forms, reports, VBA) and the data (tables). Every user who opens Access opens the same physical file. ACE uses page-level locking — when one user writes to a page, others waiting on that page block. At peak use (month-end, lunch hour), these blocks cascade into what users call "random crashes" or "Access freezes."

The structural fix is a front-end / back-end split: a shared back-end .accdb on the server holding only tables, and individual front-end .accdb copies on each user's machine holding forms, reports, queries, and VBA. This eliminates the page-lock contention for interface objects and dramatically reduces exclusive-section duration.

Step-by-step fix for crash & lock issues

1. 1Confirm the database is un-split. Open the Navigation Pane. If you see both tables AND forms/reports in the same file, it is un-split. Split using Database Tools → Access Database in Access 2016+. Test on a copy first — splitting is not reversible without manual work.
2. 2Check for orphaned sessions holding exclusive locks. Read the .laccdb file beside the back-end. If a machine listed there is powered off or disconnected, the session is orphaned. Delete the .laccdb file manually only when confirmed zero users are connected — ACE will recreate it on next open.
3. 3Audit VBA for exclusive-open patterns. Search all VBA modules (Ctrl+Shift+F in the VBA IDE) for dbOpenTable and dbDenyWrite. These open tables in exclusive mode. Replace with dbOpenDynaset for edit operations unless exclusivity is genuinely required.
4. 4Set record-level locking for bound forms. In Access Options → Advanced → Default Record Locking, set to "Edited Record" instead of "All Records." This narrows the lock scope from the whole table to the single record being edited.
5. 5Package and deploy front-end copies per user. After splitting, each user should have their own front-end copy — not all opening the same front-end file from a shared folder. Create a deployment script or batch file that copies the latest front-end to each user's local AppData folder on open.

Fix: corruption & Compact & Repair loops

File corruption in Access follows predictable triggers: improper shutdown during a write, a network interruption mid-transaction, running out of disk space during Compact, or editing the live back-end from the wrong shortcut. The safe repair sequence below works for the majority of corruption scenarios without risking data loss.

Safe corruption repair sequence

1. 1Copy the file first — always. Copy the damaged .accdb to a folder where you have full control. Name it with today's date and "repair" in the filename. Never run any repair tool on the original. If the original is the only copy, your backup cadence needs fixing before anything else.
2. 2Run Compact & Repair on the copy. File → Close & Compact, or via the Database Tools ribbon. If it completes without error and the database opens, test every key table and form. If Compact fails or hangs, do not retry — move to the next step.
3. 3Import healthy objects into a new blank database. Create a new blank .accdb. Use External Data → Access to import from the corrupted copy. Import tables first (without relationships), then queries, then forms and reports. If import fails on a specific object, skip it — that object is the corrupted one. Rebuild it from spec or a backup.
4. 4Restore relationships and test data integrity. After import, recreate relationships in the new file. Run row-count checks on every critical table against your last known good backup. Flag any discrepancies before users touch the restored file.
5. 5Investigate and fix the corruption trigger. Corruption that recurs means the trigger is still present. Common recurring causes: un-split file on a network with drops, no graceful shutdown on the Access host machine, antivirus scanning the .accdb mid-write. Add the backend folder to AV exclusions and enforce a split architecture.

Fix: runtime & VBA errors

Runtime errors fire during execution — not at startup — which makes them harder to catch than compile errors. The four most common runtime error patterns in production Access databases:

How to /decompile Access — strip corrupted p-code

The /decompile switch strips compiled VBA bytecode and forces Access to rebuild it clean from your source text. This is the fix for "ghost" runtime errors — errors that fire on lines that look syntactically correct, appearing only after an Office update or a machine rebuild. It does not touch your data tables. Always run on a backup copy.

REM ── /decompile — strip corrupted p-code and force clean recompile ──
REM ── Run ONLY on a backup copy. Close ALL Access instances first. ──

REM ── 1. Verify no msaccess.exe processes are running ──
tasklist | findstr msaccess

REM ── 2. Run decompile (adjust path for your Office version/bitness) ──

REM 32-bit Office on 64-bit Windows:
"C:Program Files (x86)Microsoft Office
ootOffice16MSACCESS.EXE" ^
  /decompile "C:Backupscompany_fe_backup.accdb"

REM 64-bit Office:
"C:Program FilesMicrosoft Office
ootOffice16MSACCESS.EXE" ^
  /decompile "C:Backupscompany_fe_backup.accdb"

REM ── 3. Once Access opens the file, go to VBA IDE immediately ──
REM    Alt+F11 → Debug → Compile VBAProject
REM    Fix every compile error before doing anything else.
REM    Do NOT let users open the file between decompile and compile.

REM ── 4. After a clean compile, run Compact & Repair ──
"C:Program FilesMicrosoft Office
ootOffice16MSACCESS.EXE" ^
  /compact "C:Backupscompany_fe_backup.accdb"

REM ── 5. Test thoroughly before replacing the production front-end ──

For a deeper walkthrough of specific runtime error codes (3044, 3146, 3048, 3734), see our MS Access runtime error fix guide →

Fix: ODBC & SQL Server failures (error 3146)

Error 3146 ("ODBC — call failed") is a wrapper. The top-level error number tells you nothing useful — the real cause is in the inner ODBC driver error that follows in brackets. Always read the full error chain before diagnosing.

Read the full ODBC error chain in VBA

Add this temporarily to your error handler when 3146 occurs:

' In your error handler, loop DBEngine.Errors for the full chain:
Dim e As DAO.Error
Dim msg As String
For Each e In DBEngine.Errors
    msg = msg & "Error " & e.Number & ": " & e.Description & vbCrLf
Next e
MsgBox msg, vbCritical, "Full ODBC Error Chain"

Common ODBC causes and fixes

1. 1"Login timeout expired" — SQL Server unreachable. Test TCP connectivity to port 1433 from the affected machine: Test-NetConnection sql-server-name -Port 1433 in PowerShell. If it fails, the problem is firewall or DNS — not Access.
2. 2"SSL Provider: handshake failed" — TLS version mismatch. Legacy ODBC drivers (SQL Server Native Client 11.0) do not support TLS 1.2+ required by SQL Server 2019 and later. Update to Microsoft ODBC Driver 18 for SQL Server. Update the DSN in ODBC Data Sources matching your Office bitness — 32-bit Access needs the 32-bit ODBC administrator.
3. 3"Communication link failure" — VPN or Wi-Fi drop mid-operation. Enable TCP keep-alive in the ODBC driver settings (ODBC Administrator → your DSN → Advanced → Enable Keep Alive). For long-running queries, increase QueryTimeout: DBEngine.QueryTimeout = 120. Move reports that pull large SQL Server datasets to pass-through queries with their own timeout setting.
4. 4"Invalid object name 'dbo.TableName'" — schema prefix or permission issue. Verify the linked table owner prefix in the linked table properties. Grant SELECT (and INSERT/UPDATE/DELETE as needed) to the SQL login used by the ODBC connection. Check that the DSN points to the correct database name — a recent infrastructure change may have renamed the database.

Fix: missing references after Office updates

Broken references are the most common cause of VBA runtime errors after an Office update, a Windows rebuild, or moving a database to a new machine. When a type library (DLL) path changes, Access marks it as MISSING: — and any code using types from that library throws a runtime error on first execution, even if it compiled cleanly before the update.

1. 1Open Tools → References in the VBA IDE (Alt+F11). Any library marked MISSING: at the top of the list must be fixed before proceeding.
2. 2Note the full name of each MISSING library. The label after "MISSING:" is the original library name (e.g. "Microsoft DAO 3.6 Object Library"). You need to find the correct replacement for your Office version and bitness.
3. 3Uncheck the MISSING entry, then re-check the correct version. Scroll the list to find the correct version matching your installed Office. If it is not in the list, click Browse and navigate to the DLL or TLB manually.
4. 4Run Debug → Compile VBAProject. A clean compile with no errors confirms all references resolve. Deploy the fixed front-end to all users — references are stored inside the .accdb, so the fix travels with the file.

Fix: per-user crashes — works for some, fails for others

When Access errors only affect certain users while others work fine on identical tasks, the database itself is almost never the problem. The cause is environmental mismatch between that user's machine and the machines where it works. Check these four areas in order:

1. 1Office build channel and version. File → Account → About in any Office app. Compare the full build number (e.g. 16.0.17628.20144) between working and failing machines. Different build channels carry different ACE engine versions — a bug fixed in Current Channel may still be present in Semi-Annual Channel.
2. 2Front-end file date and version. Check the file modification date of the .accdb the affected user is running. If they have an older copy than everyone else, their references and compiled modules are out of date. Deploy a fresh copy and test.
3. 3Office bitness — 32-bit vs 64-bit. A database with any 32-bit API Declare statements (without PtrSafe) will crash on 64-bit Access. Run Debug → Compile on the failing machine — 64-bit compile errors that don't appear on 32-bit will surface immediately.
4. 4Trust Center and macro security settings. File → Options → Trust Center → Trust Center Settings → Macro Settings. If the affected user has "Disable all macros without notification," VBA will not run and errors will be cryptic. Add the network share to Trusted Locations or set a consistent macro security policy via Group Policy.

Safe repair protocol — the sequence that protects data

Every repair step we take in production follows this sequence. The order matters — skipping backup before repair or running Compact on the live file are the two mistakes that turn a recoverable situation into a data loss event.

1. 1

   Backup before anything

   Copy both front-end and back-end .accdb files to a dated backup folder. Confirm the copy completed and the backup file size matches the original. Only then proceed.

2. 2

   Read-only assessment

   Open the backup copy as read-only (hold Shift on open to bypass AutoExec). Navigate the object list. Note which objects open and which throw errors — this tells you the scope before any repair.

3. 3

   Compact & Repair on the copy

   Run Compact & Repair on the backup copy only. If it succeeds, test every critical table and form. If it fails or hangs, move directly to import.

4. 4

   Import into a new blank database

   Create a new .accdb. Import from the backup copy object by object — tables first, then queries, then forms and reports. An object that fails to import is the corrupted one. Skip and rebuild from spec.

5. 5

   Test under realistic conditions

   Open the repaired file as a normal user (not admin). Run the exact workflow that failed. Test with multiple simultaneous users if the issue was multi-user. Only promote to production after passing these tests.

6. 6

   Document and deploy

   Write down what you found and what you changed — which objects were corrupted, what the root cause was, what was rebuilt. Your IT team needs this to verify the fix holds and to prevent recurrence.