Access Runtime Error 3061, 2501, or 94: Causes and Fixes

Access Runtime Error 3061, 2501, and 94 are three different failures—not variations of the same bug. Jump to the section that matches your exact message; each block is written to stand alone if that is the only error you care about. For path/permission write failures after the file opens, use Access runtime error 3044. Broader triage lives in our MS Access runtime errors fix guide.

Jump to your error:

• [Error 3061 — Too few parameters](#access-runtime-error-3061-too-few-parameters-expected-n)
• [Error 2501 — The OpenForm action was canceled](#access-runtime-error-2501-the-openform-action-was-canceled)
• [Error 94 — Invalid use of Null](#access-runtime-error-94-invalid-use-of-null)

Access Runtime Error 3061: Too Few Parameters. Expected N.

Quick answer: Runtime Error 3061 ("Too few parameters. Expected N.") means Jet/ACE found N unresolved parameters in your SQL or saved query—usually a misspelled field name, a `Forms!FormName!Control` reference that does not resolve, or VBA that runs a parameterized query without supplying those values. Fix the name mismatch or pass parameters through a `QueryDef` before you open the recordset.

What Causes This Error

Access treats unknown identifiers in SQL as parameters. If you write `WHERE CustomerID = Forms!frmOrders!txtID` and the form is closed, the control is misspelled, or the form name changed, Access asks for a parameter you never intended to prompt for. In VBA, `CurrentDb.OpenRecordset("qryFiltered")` on a query that expects parameters fails the same way when nothing fills them.

The number in "Expected N" is a count of unresolved tokens—not a line number. Expected 1 is the most common; Expected 2+ means multiple bad references or intentional parameters you forgot to set.

3061 also appears when a field was renamed in the table but not in the query SQL, or when brackets were dropped around names with spaces. It is a resolution problem, not a permissions problem.

How to Fix It

1. Open the failing query in Design View or SQL View. Run it alone. Note every parameter prompt Access shows—those names are what Jet cannot resolve.
2. Compare each prompt to real table field names and to open form control names. Fix typos; reopen the form before the query runs if you rely on `Forms!...` references.
3. Prefer explicit criteria from VBA instead of buried `Forms!` references when automation runs with no UI.
4. For parameterized queries in code, use a `QueryDef` and set each parameter before `OpenRecordset` or `Execute`.

Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset

Set db = CurrentDb
Set qdf = db.QueryDefs("qryOrdersByCustomer")
qdf.Parameters("[CustomerID]") = Me!txtCustomerID
Set rs = qdf.OpenRecordset(dbOpenSnapshot)

1. If you build SQL in a string, concatenate validated values (or use parameters) instead of hoping Access will prompt. Never leave a field name misspelled inside the string—Access will promote it to a parameter and throw 3061 when VBA supplies none.
2. Compile the project (Debug > Compile) after renames so leftover references surface before users hit them at runtime.

Access Runtime Error 2501: The OpenForm Action Was Canceled

Quick answer: Runtime Error 2501 means an Access action—usually OpenForm, OpenReport, OpenQuery, or SendObject—did not finish. The message often says the action "was canceled." Users clicking Cancel on a dialog can cause it, but silent cancels from a missing object name, a failed `WhereCondition`, permissions, or `Cancel = True` in an event are more common in production apps.

What Causes This Error

Macros and `DoCmd` calls report 2501 when the target action aborts. Classic cases: `DoCmd.OpenForm "frmInvoice"` when `frmInvoice` was renamed; a `WhereCondition` that creates invalid SQL; AutoExec opening a form the Trust Center blocks; or a form's `Open`/`Load` event setting `Cancel = True` after a validation failure.

It also appears when a report's record source errors during open—Access cancels the OpenReport action and surfaces 2501 instead of the underlying query error. Always dig one layer deeper: what failed inside the open?

2501 is not "Access is broken." It is Access telling you the open did not complete. Treat the previous action and the target object's events as the real debugging surface.

How to Fix It

1. Note the exact action in the message (OpenForm vs OpenReport vs OpenQuery). That names the `DoCmd` or macro line to inspect.
2. Confirm the object name still exists in the Navigation Pane. Update every `DoCmd`, macro, and button after renames.
3. Temporarily comment out `WhereCondition` / filter arguments. If the form opens bare, the filter SQL is the culprit—fix quotes, dates, and field names.
4. Open the form/report manually. If it errors on its own, fix that object first; 2501 is only the wrapper.
5. In the form's `Form_Open` (or report open) event, search for `Cancel = True` and any validation that aborts open. Log the reason before canceling so 2501 is not a mystery.
6. Wrap automation with an error handler that distinguishes user cancel from unexpected failure:

On Error GoTo Handler
DoCmd.OpenForm "frmOrders", , , "CustomerID = " & Me!txtCustomerID
Exit Sub

Handler:
    If Err.Number = 2501 Then
        ' Open canceled — log WhereCondition / missing form / Cancel=True path
        Debug.Print "OpenForm canceled: " & Err.Description
    Else
        MsgBox "Unexpected: " & Err.Number & " — " & Err.Description
    End If

1. Check Trust Center and disabled mode if opens fail only for some users—security blocks often cancel the action without a clear business message.

Access Runtime Error 94: Invalid Use of Null

Quick answer: Runtime Error 94 ("Invalid use of Null") means VBA performed an operation that requires a value on something that is Null—a field, control, or variable. Concatenation, math, and assignment into typed non-Variant variables are the usual triggers. Guard with `IsNull` / `Nz` before you use the value.

What Causes This Error

Null is not an empty string and not zero. In Access VBA, `Null & "x"` can be fine in some contexts, but `CLng(Null)`, `Null + 1`, and assigning Null into a `Long` or `String` variable throw 94. Bound controls on new records, optional fields, and outer-join queries return Null constantly in real databases.

The bug is almost always assuming a control or field "always has data." It does not—especially on the first row of a new form, after a filter returns no match, or when a user clears a required-looking field that the table still allows to be Null.

94 is a data assumption failure. Fixing it means handling Null at the point of use, or preventing Null upstream with defaults and validation—not disabling error handling so the crash disappears.

How to Fix It

1. Find the line from the VBA debugger (Debug > Compile, then reproduce). Note which variable, field, or control is Null when it breaks.
2. Before math or typed assignment, test with `IsNull` or coerce with `Nz`.
3. For text display, prefer `Nz(Me!txtName, "")` so concatenation never sees Null.
4. For numeric work, decide a business default: `Nz(Me!Quantity, 0)`—only if zero is a valid stand-in.
5. Avoid declaring `Dim x As String` then assigning a possibly-Null field; use `Variant` until validated, or Nz first.

Dim qty As Long
Dim labelText As String

If IsNull(Me!Quantity) Then
    MsgBox "Quantity is required."
    Me!Quantity.SetFocus
    Exit Sub
End If

qty = CLng(Me!Quantity)
labelText = Nz(Me!ProductName, "(no name)") & " — qty " & qty

1. In queries feeding reports, use `Nz()` in SQL for columns the report footer sums, or handle Null in the report's Format event—same class of failure, different surface.
2. Add table-level defaults or Required where business rules demand a value, so Null never reaches code that cannot accept it.

Still Getting Errors After Trying These Fixes?

When the same runtime errors return after parameter fixes, Cancel tracing, and Null guards, look past the one line of code. Broken VBA references, a corrupted form module, renamed queries still called from macros, or a front-end that drifted from the back-end schema will keep generating "new" 3061/2501/94 symptoms that are really environment drift. Compile the project on every workstation image you ship, and confirm MISSING references after Office updates before chasing more SQL tweaks.

If you need that deeper pass—compile cleanup, reference repair, and structured debugging—start with Access database development. That is the right next step after the code-level fixes above stop helping.

Frequently Asked Questions