Share via

Access no longer able to create new records in a linked SQL table following recent updates

Pete Hadden 1 Reputation point
2026-04-28T08:47:42.03+00:00

For some reason when saving a new record into a linked SQL table that contains nvarchar fields (works ok otherwise) Access throws up a 3155 error. On inspecting the SQL insert statement on the SQL server using XEEvent Profiler, an incorrectly formatted SQL Insert statement is being used whereby the statement ends with "SELECT = _id FROM @_si"

When there is no nvarchar fields involved this incorrect "select =...." clause is not there and everything works fine.

This has only started happening in the last week or so. The SQL server info is

Microsoft SQL Server Management Studio 14.0.17289.0

Microsoft Analysis Services Client Tools 14.0.1016.283

Microsoft Data Access Components (MDAC) 10.0.26100.3624

Microsoft MSXML 3.0 6.0

Microsoft Internet Explorer 9.11.26100.0

Microsoft .NET Framework 4.0.30319.42000

Operating System 6.3.26200

The version of Access is Microsoft 365 MSO (Version 2604 Build 16.0.19929.20086) 64-bit

I suspect this has occurred since the build version of Access changed to 2604. Can Microsoft please correct this with a new release as its causing a real headache with multiple users and systems.

Microsoft 365 and Office | Access | For business | Windows

Answer recommended by moderator

George Hepworth 22,855 Reputation points Volunteer Moderator
2026-04-28T15:12:15.63+00:00

As of this morning, April 28, 2026, this bug has been fixed. You will need to restart Access to get the fix.

Was this answer helpful?

4 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Pete Hadden 1 Reputation point
    2026-04-29T07:11:28.1566667+00:00

    OK - so I've managed to get things working again by upgrading my ODBC SQL Server Driver to version 18. I think my systems had been using whichever SQL server driver came with SQL Server (SMS v17.9.1), just called 'SQL Driver'.

    So I now need to install this onto all the client PCs, and then deploy a new client accdb file that uses this new ODBC driver for the table link-up. I just hope the switch to the new driver doesn't introduce any other unexpected surprises....

    Was this answer helpful?

  2. Karl Donaubauer 3,191 Reputation points
    2026-04-28T11:34:56.58+00:00

    Hi,

    This is a known bug in the current build of Office. For the latest news and all workarounds you can read our documenting AFo article.

    Servus
    Karl

    Access Forever News DevCon
    Access-Entwickler-Konferenz AEK

    Was this answer helpful?

    0 comments
  3. Michelle-N 16,635 Reputation points Microsoft External Staff Moderator
    2026-04-28T11:14:10.89+00:00

    Please note that this is a user-to-user support forum. Moderators and contributors, including external Microsoft employees, cannot directly intervene in Microsoft product features or access back-end systems. Our role is limited to providing technical guidance on reported issues, requests, or ideas.

    Hi @Pete Hadden

    Based on the information you provided, I understand that you are encountering Error 3155 when saving records into a linked SQL table containing nvarchar fields, specifically after updating to Office Build 2604. You've also noted the malformed SQL statement ending in SELECT = _id FROM @_si via the XEEvent Profiler.

    After doing some research, I’ve found that many other users are experiencing this same behavior on Build 2604. The issue seems to trigger when SQL Server tables have nvarchar(max) columns or fields that map to Long Text within Access.

    While we wait for a permanent fix, here are the most feasible workarounds currently available:

    Note: This information is provided as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.

    Please note that there has not been an official announcement from Microsoft regarding this specific behavior yet. Because of this, I highly recommend contacting support directly through the Help > Contact Support button in Access. This will allow the backend team to collect more data and address the issue as quickly as possible.

    I hope this helps get your database back up and running! If there is any official information, I will let you know.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

    0 comments

  4. AI answer

    2026-04-28T08:47:59.86+00:00

    The behavior matches known regressions where recent Access builds break operations against linked SQL Server tables. Similar issues have occurred when Access mis‑handles identity or datetime/datetime2 columns, causing errors or “#Deleted” rows after updates.

    From the context, the supported and recommended actions in comparable cases are:

    1. Update Access to a fixed build
      • For previous regressions (for example, identity columns not recognized, or “Query is corrupt”), Microsoft released fixes in later builds and explicitly recommended forcing an update via File → Account → Update Options → Update Now in an Office app.
      • Apply the latest Microsoft 365 Apps updates so Access moves off the problematic build (in this case, Version 2604 build 16.0.19929.20086) to a newer build that may contain a fix.
    2. If on an Insider/preview channel, move to Current Channel
      • For the identity‑column bug, the fix was delivered first to Current Channel, and users on Insiders channels were advised to switch channels until the fix arrived there.
      • If Access is on an Insider or preview channel, switch to Current Channel, update, and then test inserts again.
    3. Refresh the linked tables after updating
      • After Access fixes that affect how it interprets SQL Server metadata (identity, datetime/datetime2, etc.), Microsoft explicitly instructs to refresh linked tables using Linked Table Manager so Access rebuilds the link definitions.
      • After updating Office/Access and possibly changing channel, open Access → External Data → Linked Table Manager, select the affected SQL Server tables, and refresh them.
    4. Check for datetime/datetime2 with fractional seconds in keys
      • For other regressions, Access mis‑handled datetime/datetime2 columns with fractional seconds when the SQL Server database compatibility level was 130 or higher, causing #Deleted and write conflicts.
      • If the affected table uses datetime/datetime2 columns (especially in primary keys or unique indexes), apply one of the documented workarounds if updating Access does not resolve the issue:
        • Lower the database compatibility level to 120 or less.
        • Ensure datetime/datetime2 columns are not part of the primary key.
        • Add a timestamp/rowversion column.
        • Remove fractional seconds from datetime values via UPDATE.
        • Change datetime to smalldatetime (noting it rounds to the nearest minute).
        • If only read‑only access is needed, use a query with RecordsetType set to Snapshot.
    5. If the issue persists, open a Microsoft support case
      • For serious regressions introduced by Office updates, the documented guidance is to open a support case so the issue can be escalated and fixed in a subsequent build.

    In summary, the supported path is to: update Access to the latest build (and, if necessary, move to Current Channel), refresh the linked tables, and, if the problem remains, apply the documented SQL Server workarounds for datetime/datetime2 issues or escalate via a Microsoft support case.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.