Access Error 3151 ODBC Connection Failed: Linked Tables Stop Working

Fix it now

Access is relaying a refusal from the ODBC layer, and the number tells you nothing about why. The database and the link definitions are fine; the driver, the data source, the credentials or the route to the server has changed. Test the connection outside Access first, then relink.

1. Test the server on its own, before touching Access: Test-NetConnection sql01 -Port 1433 in PowerShell. False means the network or a firewall, and Access is innocent.
2. Open the ODBC administrator that matches the Access build, not the one on the Start menu. A 32-bit Access needs the copy of odbcad32.exe in the SysWOW64 folder; a 64-bit Access needs the one in System32.
3. Find the data source, choose Configure, and use Test Data Source at the end of the wizard. If it fails there, fix it there and stop reading.
4. If the failure started on a rebuilt or freshly patched machine, look at the driver version. Microsoft changed the default: the Encrypt keyword defaults to yes in ODBC Driver 18 for SQL Server and later, and to no in earlier versions.
5. In Access, open the Linked Table Manager, tick the affected tables and relink them with the corrected connection details.

Relink every table, not the one you tested. A partial relink leaves half the application pointing at a connection string that has already been proven wrong.

If a linked table opens and shows records, you are done. If it still fails, the next section covers the four things that break a stored connection and how to tell them apart.

Why it happens

A linked table is not a copy of anything. It is a stored connection string plus the name of an object at the far end. Every time a form opens, a query runs or somebody scrolls a datasheet, Access hands that string to the ODBC driver manager and asks it to do the work. If any part of the string no longer describes reality, everything that touches the table fails at once – which is why the symptom is usually total rather than partial, and why one failing table almost never means one failing table.

Bitness is the most misunderstood part of this. A 64-bit ODBC administrator manages 64-bit data sources and a 32-bit one manages 32-bit data sources, and neither can see the other’s. Which one you need is decided by the Access installation, not by Windows, so a data source that tests perfectly can be invisible to the application that needs it. Two separate administrators exist for exactly this reason.

The other frequent cause is a driver default that changed. Microsoft states that the Encrypt connection keyword defaults to yes in ODBC Driver 18 for SQL Server and later, and defaulted to no before that. A server without a certificate the client trusts is therefore refused by a driver that connected happily a version earlier, and the symptom appears the moment a workstation is rebuilt rather than gradually. Worth knowing while you argue about it: Microsoft also states that the login credentials are encrypted regardless of the Encrypt setting.

Full reference

Relinking many tables at once

Dim td As DAO.TableDef
For Each td In CurrentDb.TableDefs
    If Len(td.Connect) > 0 Then
        td.Connect = "ODBC;DRIVER={ODBC Driver 18 for SQL Server};" & _
                     "SERVER=sql01;DATABASE=Sales;Trusted_Connection=Yes;" & _
                     "Encrypt=Yes;"
        td.RefreshLink
    End If
Next td

Take a copy of the front-end before you run anything that rewrites every link in it. If the string is wrong you will have replaced a set of links that were merely stale with a set that are uniformly broken, and there is no undo.

Driver defaults that changed underneath you

DSN or DSN-less

• A DSN-less connection string travels inside the database, so a new workstation needs nothing configured on it.
• A named data source is worth keeping where a central team manages it deliberately and wants one place to change the server name.
• A User DSN is the worst of both: invisible to other profiles, invisible on a new machine, and easy to create by accident.
• Whichever you use, record the driver name and version somewhere, because that is the field that changes underneath you.

What the numbers are, and are not

Microsoft publishes no error-number reference for the Access database engine, so 3151, 3146, 3155 and 3059 have no vendor-defined meanings to quote. What is useful about them is where in the sequence they appear: the connection refusal, the failed call underneath it, a rejected write, and a cancelled operation. Read the driver’s own error text, which appears under the Access message and is the part that actually names the problem.

When it breaks for everybody at once

Something shared changed: a server rename, a firewall rule, a certificate expiry, a login disabled, a service moved. When only some users are affected, look at the client side instead – the Access build, the bitness of the data source, the DSN scope and the driver version. That single split saves more time on this error than any other check, because the two halves have no fixes in common.

Every code this article covers

Confirm the fix worked

1. Open one linked table in datasheet view and confirm records appear rather than a connection error.
2. Run a query that joins two linked tables, to confirm the whole set relinked rather than the one you tested.
3. Insert and delete a test record, to confirm write access as well as read.
4. Close and reopen the database and confirm no login prompt appears if you did not intend one.
5. Repeat on a second workstation, because bitness and driver version are per machine.

Questions people ask about this