You ran the migration tool. The tables are on the new server. The linked tables are set up. You open the database and… things are broken.

This is normal. Every Access migration produces a list of things that do not work the way they used to. The good news is that these problems are predictable. Here are the seven most common issues and how to fix each one.

1. Boolean Fields Display Wrong Values

What happens: Your Yes/No checkboxes on forms show the wrong state, or queries that filter on True/False return unexpected results.

Why: Access stores Boolean values as 0 (False) and -1 (True). SQL Server uses 0 and 1. MySQL uses 0 and 1 with TINYINT(1). PostgreSQL has a native BOOLEAN type using TRUE and FALSE.

If your VBA code checks If rs!MyField = True this works fine because VBA evaluates any non-zero value as True. But if your code checks If rs!MyField = -1, it will fail on every database except Access.

Fix: Search your VBA code for any explicit comparisons to -1 and change them to True or <> 0. In queries, replace WHERE MyField = -1 with WHERE MyField = True or WHERE MyField <> 0.

2. Date Formats Cause Errors

What happens: Forms that worked fine with dates now throw errors, queries that filter by date return no results, or date values display incorrectly.

Why: Access is very flexible about dates. It accepts “6/15/2026”, “June 15, 2026”, “15-Jun-2026”, and many other formats. It wraps dates in # delimiters in queries: WHERE OrderDate > #6/15/2026#.

Server databases are stricter. SQL Server expects dates in 'YYYY-MM-DD' format (with single quotes, not hash marks). MySQL and PostgreSQL are similar. The # delimiter is an Access-only syntax.

Additionally, Access stores dates internally as floating-point numbers (days since December 30, 1899), while server databases use proper date types. Edge cases like empty dates, zero dates, or dates before 1753 (SQL Server’s minimum for datetime) will cause errors.

Fix: In pass-through queries and VBA code that builds SQL strings, use 'YYYY-MM-DD' format with single quotes. Replace any # date delimiters with single quotes. For empty or null dates, use NULL instead of an empty string. Check for any dates before 1753 in your data before migrating if targeting SQL Server.

3. AutoNumber Gaps Panic Users

What happens: Users notice that new record IDs are not sequential. After inserting records 1045, 1046, and 1047, the next record might be 1050.

Why: Access AutoNumber fields generate sequential integers with no gaps under normal use. Server databases use identity columns (SQL Server), AUTO_INCREMENT (MySQL), or SERIAL (PostgreSQL), which can produce gaps. Gaps occur when a transaction is rolled back, a record is deleted, or the server is restarted.

This is expected behavior. Identity values are not meant to be sequential — they are meant to be unique.

Fix: This is not actually a problem, but users will report it as one. Explain that the ID is a unique identifier, not a sequence number. If you need sequential numbers (like invoice numbers), create a separate counter mechanism rather than relying on the identity column.

In VBA code, if you use rs.LastModified or DMax("ID", "TableName") to get the newly inserted ID, replace this with the server’s proper mechanism. For SQL Server, use SELECT SCOPE_IDENTITY(). For MySQL, use SELECT LAST_INSERT_ID(). For PostgreSQL, use RETURNING id in the INSERT statement.

4. Queries with Access-Specific Functions Fail

What happens: Queries that worked in Access return errors like “undefined function” or produce wrong results.

Why: Access has many built-in functions that do not exist in other databases. When the query runs through a linked table, Access tries to send it to the server, and the server does not recognize the function.

Common offenders:

Fix: For queries that run through linked tables (bound forms, Access query designer), Access often handles the translation automatically. For pass-through queries and VBA-built SQL strings, you need to manually translate to the target database’s syntax.

5. Records Appear Blank or “#Deleted”

What happens: After linking tables, some records show “#Deleted” or all fields appear blank when you scroll through a table or form.

Why: This is usually caused by one of two issues:

Fix: Ensure every linked table has a primary key on the server. When you first link a table without a primary key, Access asks you to select a unique identifier — choose one, or better yet, add a proper primary key on the server first. If the problem is a structure mismatch, re-link the table through the Linked Table Manager to refresh the cached structure.

6. Forms Are Slower Than Before

What happens: Forms that opened instantly now take several seconds to load, or scrolling through records is noticeably laggy.

Why: In a pure Access database, reading from a local file is fast. With linked tables, every data operation travels over the network through the ODBC layer. Several patterns that were fine with local data become performance problems over ODBC:

Fix: Add WHERE clauses to form record sources so they load only the needed records. Replace DLookup calls with a single query. Limit combo box row sources to a reasonable number of items, or use a search-as-you-type pattern. Consider converting complex data retrieval to pass-through queries.

7. Multi-Value and Attachment Fields Do Not Migrate

What happens: Columns that used Access multi-value fields or Attachment data types are missing or contain garbage after migration.

Why: Multi-value fields and Attachment fields are Access-specific features with no equivalent in server databases. They are actually complex data structures stored in hidden system tables. No migration tool can convert them to standard SQL database columns because the concept does not exist in other databases.

Fix: Before migration, restructure multi-value fields into proper relational tables (a junction table for many-to-many relationships). For Attachment fields, extract the files to a file system location and store the file path in a text column, or convert to a BLOB/VARBINARY column for binary storage.

These fields must be restructured before migration — this is not something you can fix after the fact.

The Pattern

Notice that most of these problems fall into two categories: things that Access did in a nonstandard way (Boolean values, date handling, proprietary functions), and things that are genuinely different between a file-based and server-based architecture (performance patterns, identity gaps).

The first category requires code changes. The second requires rethinking how your application interacts with data. Both are manageable if you expect them and plan for them before you start the migration.