Expert guide
Access 'ODBC--Call Failed': Find the Real Error and Fix It
The message is generic. The cause is in the details, and there are only a few of them
Call us at +1 (385) 386-3860
Short answer: "ODBC--call failed" only says that SQL Server (or another ODBC source) rejected a request. Read DBEngine.Errors to get the real server error, then fix the usual suspects: login or permissions, driver encryption and certificate settings, unreachable server, query timeouts, constraint or trigger errors on save, and linked tables that no longer match the server schema. A DSN-less relink routine prevents most connection problems. Our Access to SQL Server projects include this hardening.
Once an Access database has SQL Server linked tables, "ODBC--call failed" becomes the error everyone sees and nobody understands. It can mean the server is down, the user's password expired, a new driver tightened security, a query took too long, or a save broke a database rule. The first step is always the same: get the real message.
Step 1: Read the Real Error
Public Function OdbcErrorDetail() As String
Dim e As DAO.Error, s As String
For Each e In DBEngine.Errors
s = s & e.Number & " - " & e.Description & " [" & e.Source & "]" & vbCrLf
Next e
OdbcErrorDetail = s
End Function
' In an error handler:
Fail:
If Err.Number = 3146 Then ' 3146 = ODBC--call failed
MsgBox OdbcErrorDetail(), vbExclamation, "Database error"
Else
MsgBox Err.Number & ": " & Err.Description
End IfThe DBEngine.Errors collection holds the chain of errors from the ODBC driver and SQL Server. The first entries usually contain the SQL Server error number and a clear message such as "Login failed for user" or "The INSERT statement conflicted with the FOREIGN KEY constraint".
Common Causes and Fixes
| Real error contains | Cause | Fix |
|---|---|---|
| Login failed for user | Wrong credentials, disabled login, no database permission | Fix the login or use Windows authentication; grant database access |
| SSL / certificate chain was issued by an authority that is not trusted | Newer ODBC driver encrypts and validates the certificate | Install a trusted certificate on the server; TrustServerCertificate=yes only as a stopgap |
| Named Pipes / TCP provider error, server not found | Server unreachable, firewall, wrong instance name, VPN down | Test with SSMS from the same PC; check port 1433 or the instance's port |
| Query timeout expired | Slow query or blocking | Fix indexes or move logic to a view; raise ODBC Timeout as a short-term measure |
| conflicted with the FOREIGN KEY / CHECK constraint | The save breaks a database rule | Validate in the form before saving; fix the data |
| Cannot insert the value NULL into column | Required column not supplied | Default on the server, or required field on the form |
| Invalid column name / Invalid object name | Server schema changed; linked table definition is stale | Relink the table |
| Arithmetic overflow / string or binary data would be truncated | Value too large for the column type | Validate length and range in Access |
Driver and Connection Strings
Several SQL Server ODBC drivers can coexist on a PC: the old "SQL Server" driver, SQL Server Native Client, and the current Microsoft ODBC Driver 17 and 18 for SQL Server. Use one current driver consistently and put it in the connection string of every linked table.
DSN-less connection string (Windows authentication):
ODBC;DRIVER={ODBC Driver 18 for SQL Server};SERVER=sql01.company.local;
DATABASE=Operations;Trusted_Connection=Yes;Encrypt=Yes;
With SQL authentication (avoid storing passwords in linked tables where possible):
ODBC;DRIVER={ODBC Driver 18 for SQL Server};SERVER=sql01;DATABASE=Operations;
UID=app_user;PWD=...;Encrypt=Yes;A startup routine that checks and relinks tables to the correct server keeps every PC consistent; see relinking Access tables with VBA.
Timeouts and Slow Queries
Queries using Access functions (IIf, Nz, Format, custom VBA functions) in WHERE clauses may force Access to pull whole tables locally.
Joining a local Access table to a SQL Server table also pulls data across the network.
Move heavy aggregation into SQL Server views and link them, or use pass-through queries that run entirely on the server.
Check server indexes on the columns used in joins and filters.
Set ODBC Timeout per query (property sheet) only when a slow query is genuinely expected.
Errors When Saving Records
Tables need a primary key in SQL Server to be updatable from Access; without one, links are read-only or rows show #Deleted.
Add a rowversion column to frequently edited tables; Access uses it to detect changes efficiently and reduce write conflicts.
Bit (Yes/No) columns should not allow NULL; set a default of 0, otherwise Access can raise write conflicts.
Triggers that fail produce ODBC errors on save; the trigger's error message appears in DBEngine.Errors.
Rows showing #Deleted are covered in #Deleted in Access linked tables.
A Diagnostic Order That Saves Time
Read DBEngine.Errors. The answer is there most of the time.
Can the same user connect from the same PC with SQL Server Management Studio or a test DSN?
Did anything change: driver update, server certificate, password policy, schema change?
Is it one table or query, or every connection? One object points to schema or query issues; everything points to connection issues.
Is it intermittent and worse remotely? Look at network and timeouts.
Stable Access-to-SQL setups come from a good migration: proper keys, views for heavy queries and consistent connections. See AI-assisted Access to SQL Server migration or talk to us about Access support.
FAQ
ODBC call failed FAQ
Access with SQL Server errors