Access + ODBC driver 18 + SQL Server 2025: 150-250 ms per request when bound forms are open

Bruno De Grauwe 0 Reputation points
2026-11-06T19:27:59.4266667+00:00

Has anyone encountered recurring request latency when using Microsoft Access with SQL Server 2025 through ODBC driver 18?

In several existing Access application (currently none of them connecting to a SQL Server 2025), a simple DAO test on a SQL Server 2025 behaves as follows:
No forms open: approximately 0-4 ms per request after the initial execution
Certain bound forms (max 2) open: approximately 150-250 ms per request
Closing the affected objects restores normal performance in the tested scenarios

This affects both a two-row SELECT through a linked table and a pass-through query executing nothing more than a simple SELECT 1.

Extended Events on SQL Server 2025 measured less than 1 ms for those requests while Access measured approximately 200 ms. The test requests used the same server session.

I reproduced the behaviour on:
SQL Server 2025 Developer builds 17.0.1145.4 and 17.0.1135.8
Access 2021 and Access 2019, both 64-bit
Two ODBC Driver 18 installations

Using the same computer, Access installation and ODBC driver, the test remains fast with the forms open against SQL Server 2016 and SQL Server 2022.

Important limitations: the 2016/2022 servers contained an older database copy, and those connections are remote while the computer with the SQL Server 2025 connection is local. This is therefore evidence of an environment-dependent difference, not proof of an engine defect.

ODBC tracing was disabled. Compatibility-level changes did not resolve it. Linked SQL Server views (for the bound forms) and fully fetching some recordsets improved specific cases, but did not consistently eliminate the problem.

Has anyone seen a similar pattern, or identified a relevant setting, fox or client-side diagnostic approach? In particular, what would you capture to locate time spent outside SQL Server's recorded execution duration?

I am also arranging a Microsoft support incident and can provide the small VBA timing procedure if useful.

SQL Server Database Engine
0 comments No comments

1 answer

Sort by: Most helpful
  1. Dan Guzman 9,521 Reputation points
    2026-11-06T23:37:21.5+00:00

    Are you are using SQL authentication (instead of Windows or Entra auth)? If so, the slowness could be in the initial login process due to the the RFC2898 iterated hash algorithm introduced in SQL Server 2025. This is particularly an issue with many app connections and/or lack of connection pooling.

    Trace the process_login_finish event to determine if this is the cause. The total_time_ms field will show the duration of the login event.

    CREATE EVENT SESSION login_finish ON SERVER ADD EVENT sqlserver.process_login_finish;
    GO
    

    Although connection pooling can mitigate slowness for subsequent connections, moving to Windows or Entra authentication is the long-term solution.

    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.