If you are keeping your Access front-end while moving your data to SQL Server, MySQL, or PostgreSQL, linked tables are the bridge between the two. They let your forms and reports reference external database tables as if they were local Access tables.

When linked tables work, they are nearly invisible. When they break, they produce some of the most cryptic error messages in the Access ecosystem. Understanding how they actually work makes both setup and troubleshooting much easier.

What a Linked Table Actually Is

A linked table in Access is a pointer — not a copy. When you create a linked table, Access stores:

The data itself stays on the server. When you open a form bound to a linked table, Access sends a query over ODBC to the server, receives the results, and displays them. When you edit a record and save it, Access sends an UPDATE statement over ODBC.

You can identify linked tables in the Access navigation pane by their icon — a globe with an arrow for ODBC-linked tables, versus the plain table icon for local tables.

The ODBC Layer

ODBC (Open Database Connectivity) is a standard API for database access. It works through a layered architecture:

  1. Your Access application makes a data request (open a table, run a query)
  2. The Access database engine translates this into an ODBC function call
  3. The ODBC Driver Manager routes the call to the correct driver
  4. The database-specific ODBC driver (SQL Server, MySQL, PostgreSQL) translates the call into the server’s native protocol
  5. The database server processes the request and returns results
  6. The results travel back up the same chain

Each layer in this chain is a potential point of failure. When something goes wrong, the error message you see in Access often reflects the layer where the failure occurred, which is not always the layer where the actual problem is.

Connection Strings

The connection string tells ODBC how to reach the database. It includes the driver name, server address, database name, and authentication information. Here are examples for each major database:

SQL Server:

ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myserver;DATABASE=mydb;Trusted_Connection=yes;

MySQL:

ODBC;DRIVER=MySQL ODBC 8.0 Unicode Driver;SERVER=myserver;DATABASE=mydb;UID=myuser;PWD=mypassword;

PostgreSQL:

ODBC;DRIVER=PostgreSQL Unicode;SERVER=myserver;DATABASE=mydb;UID=myuser;PWD=mypassword;PORT=5432;

You can set up connections using a DSN (Data Source Name) configured in the Windows ODBC Data Source Administrator, or embed the connection details directly in the connection string (DSN-less). DSN-less connections are generally better for deployment because they do not require configuring each workstation separately.

How Access Translates Queries

When you open a form bound to a linked table, Access does not simply pass your query through to the server unchanged. It goes through a translation process:

  1. Access parses your query using its own SQL dialect
  2. It determines which parts can be sent to the server (remote processing) and which must be done locally
  3. It sends the server-compatible parts as ODBC queries
  4. It receives the results and performs any remaining processing locally

This translation is called “query folding” or “remote query processing.” When it works well, the server does most of the work and only the results travel over the network. When it works poorly, Access downloads entire tables and processes them locally — which is exactly the performance problem you were trying to escape.

Why Linked Tables Break

Problem 1: Driver Not Found

Error: “ODBC — call failed. [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified”

Cause: The ODBC driver specified in the connection string is not installed on the user’s machine, or the driver name does not match exactly.

Fix: Install the correct ODBC driver. Driver names are case-sensitive and must match exactly — “ODBC Driver 17 for SQL Server” is not the same as “SQL Server Native Client 11.0.” Check the installed drivers in the Windows ODBC Data Source Administrator (both 32-bit and 64-bit versions).

Important note: If you are running 32-bit Access, you need the 32-bit ODBC driver. 64-bit Access needs the 64-bit driver. This mismatch is one of the most common causes of connection failures.

Problem 2: Server Not Reachable

Error: “ODBC — call failed. [Microsoft][ODBC Driver 17 for SQL Server] TCP Provider: No connection could be made because the target machine actively refused it.”

Cause: The database server is not running, the firewall is blocking the connection, or the server address is wrong.

Fix: Verify the server is running and accepting connections. Check that the correct port is open in any firewalls between the workstation and the server (1433 for SQL Server, 3306 for MySQL, 5432 for PostgreSQL). Test the connection using the ODBC Data Source Administrator’s test function.

Problem 3: Authentication Failed

Error: “ODBC — call failed. Login failed for user…”

Cause: Wrong username or password, or the user account does not have permission to access the specified database.

Fix: Verify credentials. For SQL Server with Windows Authentication, ensure the user’s domain account has been granted access. For username/password authentication, check that the account exists and has the necessary database permissions.

Problem 4: Table Structure Changed

Error: Records appear blank, columns are missing, or you get errors when opening forms.

Cause: Someone modified the table structure on the server (added, removed, or renamed columns, changed data types) but the linked table in Access still has the old structure cached.

Fix: Refresh the linked table. In Access, right-click the linked table and select “Linked Table Manager,” then re-link the table. This forces Access to update its cached structure information.

Problem 5: Write Conflicts

Error: “The record has been changed by another user since you started editing it.”

Cause: Access uses optimistic locking by default. When you start editing a record, Access notes the current values. When you save, it checks whether the values have changed. If another user (or a server-side trigger) modified the record in the meantime, Access reports a conflict.

Fix: This is actually the correct behavior — it prevents one user from overwriting another’s changes. If it happens frequently, consider restructuring workflows so users are less likely to edit the same records simultaneously.

Performance Tips for Linked Tables

Filter early. Never bind a form to an entire large table. Use a WHERE clause or a query with criteria so only the needed records travel over the network.

Avoid heterogeneous joins. If you join a local Access table with a linked table, Access downloads the entire linked table to perform the join locally. Move both tables to the server, or restructure the query.

Use pass-through queries for complex operations. A pass-through query sends raw SQL directly to the server, bypassing Access’s query translation. This is faster for complex queries and gives you access to server-specific SQL features.

Index your server tables. Linked tables do not carry index information from the server. Make sure the columns used in WHERE clauses and JOINs are properly indexed on the server side.

Minimize round trips. Replace multiple DLookup calls with a single query. Each DLookup on a linked table is a separate ODBC round trip to the server.

The Bottom Line

Linked tables are a practical bridge between Access and a server database. They are not a permanent architectural solution — they add a translation layer that introduces complexity and potential failure points. But they let you move your data to a reliable server without rewriting your entire application, and for many organizations, that is exactly the right first step.