Two people open the same form. Both navigate to the same customer record. Both start editing. One saves. The other gets an error — or worse, Access freezes entirely.

This is not a bug. It is a fundamental limitation of how Access manages concurrent data access, and understanding the mechanics explains why it cannot be fully solved within Access.

How Access Handles Concurrent Edits

Access uses a lock file (.ldb or .laccdb) to track which users have the database open and which records are being edited. The lock file sits alongside the main database file on the network share.

When a user starts editing a record, Access writes lock information to the .ldb file. This tells other users’ instances of Access that the record (or more precisely, the data page containing the record) is in use.

There are two locking strategies:

Pessimistic Locking (Edited Record)

When a user clicks into a field and starts typing, Access immediately locks the data page containing that record. Other users who try to edit any record on the same page see a “locked” indicator and cannot save changes until the first user either saves or cancels.

Problem: Locks happen at the page level, not the row level. A data page is 4KB and typically contains multiple records. Editing row 100 might lock rows 97 through 105. Users editing completely different records get blocked because they happen to be on the same page.

Problem: If a user starts editing and then walks away from their desk, the lock persists. Other users are blocked indefinitely. There is no timeout.

Optimistic Locking (No Locks)

Access does not lock the record when the user starts editing. Instead, it notes the current values of all fields. When the user saves, Access checks whether any values have changed since the user started editing. If they have, Access reports a write conflict.

Problem: The user who saves second loses their work. They have to manually merge their changes with the other user’s changes, or discard their edits entirely.

Problem: The conflict check compares every field in the record. Even if two users edited different fields on the same record, Access reports a conflict because the record as a whole has changed.

Why It Gets Worse With More Users

The probability of a conflict increases faster than you might expect as you add users. With 5 users, the chance of two people editing the same record at the same time is low. With 15 users, it becomes likely enough to happen several times a day.

But the real issue is page-level locking. Even with pessimistic locking, conflicts occur between users editing different records that happen to share a data page. The chance of page-level conflicts grows with the square of the user count, not linearly.

On a table with 4KB pages and 200-byte records, each page holds about 20 records. With 10,000 records, there are 500 pages. With 5 concurrent editors, the chance of a page collision is small. With 20 concurrent editors, it is nearly inevitable.

When Access Actually Crashes

Locking conflicts produce error messages. Crashes — where Access freezes or closes unexpectedly — have different causes:

Stale Lock File

When a user’s machine crashes, loses network connectivity, or is shut down without closing Access, their lock entry remains in the .ldb file. This stale lock blocks other users from accessing the locked pages.

Access tries to detect stale locks by periodically checking whether the user’s machine is still responsive. But this check is unreliable over networks, especially with VPN connections or wireless networks.

When multiple stale locks accumulate and other instances of Access try to work around them, the results are unpredictable. Forms may freeze. Saves may fail silently. In severe cases, Access stops responding entirely.

SMB Protocol Conflicts

Access relies on Windows file sharing (SMB) for multi-user coordination. SMB was designed for sharing documents, not for the high-frequency read-write-lock cycle that a database requires.

SMB opportunistic locks (oplocks) can conflict with Access’s own locking mechanism. When the file server and Access disagree about the lock state, data corruption or application crashes can result.

This is worse on: - Networks with high latency - VPN connections - Wireless networks with packet loss - File servers running non-Windows SMB implementations (NAS devices, Linux Samba servers)

Corruption-Induced Crashes

When the database file becomes corrupted — due to any of the causes above — Access may crash when it tries to read the corrupted data. A form that opens a corrupted table will freeze as Access tries to parse invalid data. A query that hits a corrupted index may crash the query engine.

What You Can Do Within Access

Use Optimistic Locking

Switch from pessimistic to optimistic locking. Yes, users will occasionally see write conflict dialogs. But this is better than having records locked indefinitely by users who walked away from their desks.

In Access options: File > Options > Client Settings > Advanced > Default Record Locking > No Locks.

Shorten Edit Times

Design your forms so users are in edit mode for the shortest possible time. Instead of bound forms where users type directly into the form, use an unbound editing pattern:

  1. Display data in a read-only form
  2. User clicks “Edit” button
  3. A dialog opens with editable fields
  4. User makes changes and clicks “Save”
  5. VBA code writes the changes in a single operation

This reduces the window during which locks are held from minutes (however long the user takes to type) to milliseconds (the time to execute the save).

Reduce Record Size

Smaller records mean more records per page, which increases the chance of page-level conflicts. Counterintuitively, this means you should move large fields (Memo, OLE Object) to separate tables. This reduces the size of the frequently-edited records and makes page collisions less likely.

Split the Database

Ensure the database is split into a front-end (forms, code) and a back-end (data). Each user gets their own front-end file. This prevents front-end corruption from affecting the shared data, and it eliminates the need for Access to lock form and code objects in the shared file.

What You Cannot Fix

Page-level locking, SMB-based coordination, and the absence of a server process are architectural constraints. No amount of form redesign, VBA optimization, or network tuning changes the fundamental architecture.

Server databases solve all of these problems:

If your users are experiencing regular locking conflicts, write errors, or crashes due to concurrent editing, you have a clear signal that Access’s multi-user capabilities are insufficient for your workload. The fix is moving the data to a database designed for concurrent access.