Expert guide

Access Error 3218: Could Not Update; Currently Locked

Find out what is holding the lock, then fix the setting, form or code that causes it

Free Cost Audit

Call us at +1 (385) 386-3860

Short answer: error 3218 means the record you are writing to is locked by another user, by a form or recordset in your own session, or by an open transaction. Set default record locking to No locks or Edited record (never All records), tick record-level locking, save bound forms with Me.Dirty = False before VBA updates the same record, keep transactions short, and retry briefly on 3218/3260. If locks persist over a slow network, see Access database optimisation.

"Could not update; currently locked." usually appears in a database that has just gained a few more users, moved to a new server, or had some new VBA added. It is frustrating because it is intermittent: the same button works nine times and fails on the tenth. The cause is almost always one of a handful of patterns, and each has a clear fix.

Which Error Are You Seeing?

ErrorMessageWhat it usually points to
3218Could not update; currently lockedGeneral lock conflict, often in code
3260Could not update; currently locked by user 'X' on machine 'Y'Another person is editing the record
3188Could not update; currently locked by another session on this machineYour own form or recordset holds the record
Write Conflict dialogThis record has been changed by another user...Form edit collided with a code or other-user update
3027 / 3051Database or object is read-only / cannot open filePermissions, not locking; see the read-only guide

Cause 1: Locking Settings

File → Options → Client Settings → Advanced. These settings are per user, so check them on every PC.

  • Default record locking

    No locks (optimistic) suits most databases: records are only checked when saved. Edited record locks the record while someone types. All records locks every record in the form's recordset and causes widespread conflicts; avoid it.

  • Open databases by using record-level locking

    Tick it. Without it Access locks 4 KB pages, which can contain several records, so editing one record blocks its neighbours.

  • Form-level Record Locks property

    Each form also has a Record Locks property that overrides the default. Check heavily used forms are not set to All Records.

Even with record-level locking on, some operations, such as long text (memo) fields and action queries touching many rows, still lock at page level. That is why errors can persist after the settings are right.

Cause 2: Your Form Is Locking Your Code (3188)

A bound form with an edited, unsaved record holds that record. If a button on the same form then runs an UPDATE or opens a recordset to change it, the code collides with the form.

Private Sub cmdApprove_Click()
    On Error GoTo Fail
    If Me.Dirty Then Me.Dirty = False        ' save the form's edits first

    CurrentDb.Execute "UPDATE tblOrders SET Status='Approved' " & _
                      "WHERE OrderID=" & Me.OrderID, dbFailOnError
    Me.Refresh                               ' show the new value
    Exit Sub
Fail:
    MsgBox "Could not approve: " & Err.Number & " " & Err.Description
End Sub

Even simpler: if the form is bound to the record, set the field on the form (Me.Status = "Approved") and save, instead of running SQL against the record you are looking at.

Cause 3: Long Transactions and Big Action Queries

  • Transactions (BeginTrans ... CommitTrans) hold locks until committed. Commit in small batches.

  • An UPDATE touching thousands of rows locks many pages while it runs; schedule big updates out of hours or batch them.

  • Recordset loops that call .Edit/.Update on many rows hold locks longer than a single set-based UPDATE query.

Cause 4: Other Users Editing the Same Records (3260)

If two people genuinely need the same record at once, locking is doing its job. Reduce collisions by design: open forms filtered to the record being worked on rather than the whole table, close forms when not in use, and avoid shared "queue" records such as a single counter row that everyone updates.

To see who has the database open, read how to see who is logged into an Access database.

A Retry Pattern for Brief Locks

Public Function ExecuteWithRetry(ByVal sql As String, Optional ByVal tries As Integer = 5) As Boolean
    Dim i As Integer
    For i = 1 To tries
        On Error Resume Next
        CurrentDb.Execute sql, dbFailOnError
        Select Case Err.Number
            Case 0
                ExecuteWithRetry = True: Exit Function
            Case 3218, 3260, 3188, 3197
                Err.Clear
                Dim t As Single: t = Timer
                Do While Timer < t + 0.3 * i: DoEvents: Loop   ' back off
            Case Else
                Dim n As Long, d As String: n = Err.Number: d = Err.Description
                On Error GoTo 0
                Err.Raise n, , d
        End Select
    Next i
    On Error GoTo 0
    Err.Raise 3218, , "Record still locked after " & tries & " attempts."
End Function

Retries smooth over momentary collisions. They do not fix structural problems: if retries are needed constantly, go back to causes 1 to 3.

Cause 5: Network and Hosting

  • Back end on a mapped drive over Wi-Fi or VPN: locks are held longer and lock files can be left behind.

  • Antivirus scanning the back-end file or the .laccdb lock file on every change.

  • Users without Modify permission on the folder cannot manage the lock file properly.

  • Back end inside a OneDrive, Dropbox or SharePoint sync folder: sync tools fight Access's file locking. Never do this.

These setups also cause corruption; see Access corruption over LAN, Wi-Fi and VPN. If you have outgrown file-based sharing, moving the back end to SQL Server replaces Access's file locks with proper server-side concurrency; read Access to SQL Server migration.

Quick Diagnostic Checklist

  • Does the error happen with only one user in the database? If yes, it is your own form or code (3188 pattern).

  • Check every PC's record locking options and the form's Record Locks property.

  • Is the failing code updating a record shown on an open form with unsaved changes?

  • Is there a long transaction or bulk update running at the same time?

  • Does it get worse for remote or Wi-Fi users?

FAQ

Access record locking FAQ

Errors 3218, 3260 and 3188

Access tried to write to a record (or a page of records) that is locked, either by another user, by another form or recordset in your own session, or by an open transaction. The write is refused until the lock is released.

3218 is the general 'currently locked' error. 3260 adds the user and machine holding the lock, which usually means another person has the record open for editing. 3188 means the lock is held by another session on the same machine, very often your own form holding a record while your VBA tries to update it.

For most split databases: default record locking set to 'No locks' (optimistic locking) or 'Edited record', and 'Open databases by using record-level locking' ticked. Avoid 'All records', which locks every record in a form's recordset for the duration of an edit.

Usually because a bound form has unsaved changes on the same record the code updates. The form holds the record, the code tries to write it, and Access refuses or later shows the Write Conflict dialog. Save the form first with Me.Dirty = False before running the update.

Locking errors on their own are not corruption, but frequent locking problems over a slow or unreliable network often appear alongside corruption. If errors increase over Wi-Fi or VPN connections, address the network and consider moving the back end to SQL Server.