Why Your Access Database Is Locked for Editing (and How to Fix It)

Quick answer: An Access database locked for editing almost always traces to the hidden `.laccdb` lock file Access creates beside the `.accdb`/`.mdb` to track who holds records open. That breaks when a session crashes, the `.laccdb` is orphaned, antivirus or backup grabs the file mid-write, cloud sync (OneDrive/Dropbox) fights Access, or someone opened exclusive mode. Close every session first—then delete a stuck `.laccdb` only when nobody is in.

This is the "could not lock file" Access error / "record is locked by another user" class of failures—not a database that refuses to open at all. If Access won't open the file at all rather than just showing a lock message, see Access database won't open instead. If the file opens but updates fail as read-only, compare Access runtime error 3044.

Why Does Access Say the Database Is Locked for Editing?

How the .laccdb lock file works

When the first user opens an Access database for shared use, Jet/ACE creates a lock file next to it: `.laccdb` for `.accdb` files, or the older `.ldb` for `.mdb` files. That small file is not your data. It is a ledger of machine/user sessions and which pages or records are locked.

Access creates the lock file on first open (when the folder allows create/write/delete). It updates it as users enter and leave edit states. When the last user closes cleanly, Access deletes the lock file. That is why you normally do not see a `.laccdb` sitting idle overnight on a healthy single-user desktop file.

In normal multi-user locking, two people can open the same back-end. One can edit Customer 100 while another edits Customer 200. If both try to change the same record at once, the second user gets a lock message—expected behavior, not a bug.

When locking fails in the real world

Crashed session without a clean close. Task Manager kill, power loss, VPN drop, or a hung MSACCESS.EXE leaves entries in the `.laccdb` for a user who is gone. Everyone else then hits "Could not lock file," "record is locked by another user," or "The Microsoft Access database engine stopped the process because you and another user are attempting to change the same data at the same time."

Stale / orphaned .laccdb. The lock file remains after hours with nobody in Access. Safe to remove only after you confirm zero live sessions.

Antivirus or backup software mid-sync. Real-time scanners and backup agents that open the `.accdb` or `.laccdb` for read/write interfere with Jet/ACE's lock protocol. Symptoms spike during scheduled scans.

Network drive / OneDrive sync conflicts. Consumer sync folders rewrite whole files. Access expects SMB-style locking on a stable share. OneDrive/Dropbox + live `.accdb` is a classic "could not lock file" factory.

Exclusive mode by mistake. If Default open mode is Exclusive, the first user owns the whole file. Everyone else waits or fails. Check File > Options > Client Settings > Default open mode (Shared vs Exclusive).

How to Fix 'Access Database Locked for Editing'

Work top to bottom. Do not delete the `.laccdb` while people still have the database open.

1. Close cleanly on every machine, then delete an orphaned .laccdb

1. Ask every user to close Access (File > Close / Exit)—not just the form.
2. On each PC that used the file, open Task Manager and end leftover MSACCESS.EXE processes if any remain.
3. In Explorer, open the folder that holds the `.accdb`/`.mdb`. Show hidden/system files if needed.
4. If a `.laccdb` (or `.ldb`) is still present and nobody has the database open, delete only that lock file—not the database.
5. Reopen the database. The next shared open recreates a fresh `.laccdb`.

Deleting the lock file is safe when the ledger is stale. It is not a substitute for fixing OneDrive, exclusive mode, or an unsplit multi-user design.

2. Confirm nobody opened it in exclusive mode

1. In Access: File > Options > Client Settings.
2. Find Default open mode and set it to Shared for team databases.
3. Close Options, fully exit Access, and reopen the file.
4. If one power user always opens via a shortcut, check that shortcut is not forcing exclusive open.

Exclusive mode is fine for compact/repair maintenance windows. It is wrong for day-to-day shared editing.

3. Move the database off OneDrive, Dropbox, or syncing network folders

1. Copy the `.accdb`/`.mdb` (and related front-end if split) to a local folder or a proper Windows file server share that does not sync file contents like a consumer cloud drive.
2. Update shortcuts and linked-table paths to the new location (prefer UNC: `\\server\share\data.accdb`).
3. Remove the live database from the sync folder so OneDrive stops rewriting it.

Cloud sync and Access locking fight each other: sync wants whole-file versions; Access wants byte-range locks via `.laccdb`. That mismatch is why the same file "locks" after every save on OneDrive.

4. Exclude .accdb / .laccdb from antivirus real-time scanning

1. Open your endpoint protection console or local AV settings.
2. Add exclusions for the database folder—or at least `.accdb`, `.mdb`, `.laccdb`, and `.ldb`—per your IT policy.
3. Pause a scheduled scan window and retest multi-user edits during the quiet period.

If locks vanish when AV is quiet and return when scans run, you found the interferer. Coordinate exclusions with IT; do not disable all protection permanently.

5. If it keeps happening with multiple users, split the database

Constant "record is locked by another user" noise across a team is rarely fixed by deleting `.laccdb` every morning. It usually means one shared front-end on the network, Wi‑Fi to the back-end, or no split at all.

Proper pattern: one local front-end per user, one shared back-end on a stable wired share, short edit sessions, and no cloud sync on the live data file. Recurring lock storms are an architecture signal—not a one-off cleanup.

When This Keeps Happening With Multiple Users

If three people clear the lock file and the same errors return by lunch, the database is telling you the deployment is wrong. Unreliable Wi‑Fi shares, a single front-end everyone launches from the server, and sync folders all manufacture phantom locks faster than users can delete `.laccdb` files.

Stabilize the layout with a real multi-user Access database setup—local front-ends, shared back-end, sane locking—before you treat every lock as a mystery virus. Persistent lock storms that escalate into crashes or suspected file damage are an architecture problem: talk to our Access developers, and escalate to Access database repair when locks start coinciding with corruption symptoms.

Frequently Asked Questions