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

2 answers

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-11-07T20:08:45.2566667+00:00

    There is no published SQL Server 2025 known issue or confirmed fix matching this bound-form latency, so the next useful action is a synchronized ODBC Driver Manager and WPR capture that identifies whether the 150–250 ms occurs before, inside, or after the ODBC call.

    Your Extended Events result already establishes that SQL Server execution itself is under 1 ms; Microsoft distinguishes that server duration from network latency and application-side processing time.^1^

    1. Capture the ODBC call boundary

    ODBC Driver Manager tracing records the API calls between Access/ACE, the Driver Manager, and Driver 18, including return timing. On Windows it is enabled from the Tracing tab in ODBC Data Source Administrator.^2^

    1. Close other applications using ODBC.
    2. Open ODBC Data Sources (64-bit) under the same Windows account that runs Access.
    3. Select Tracing and choose a private log-file location.
    4. Start tracing.
    5. Perform the smallest reproducible sequence:
      • Run the warmed-up SELECT 1 with no affected form open.
      • Open one affected bound form.
      • Run the identical request once.
      • Close the form and run it once more.
    6. Stop tracing immediately and close Access.

    Tracing can expose connection strings, SQL text, and parameter values, so redact secrets and application data before sharing the file. Keep the capture short because tracing itself adds overhead.

    In the trace, compare timestamps around calls such as SQLExecute, SQLExecDirect, SQLFetch, SQLGetData, and transaction-related calls:

    • Delay before an ODBC call starts: Access/ACE or form processing.
    • Long duration inside an execute/fetch call, while XE remains under 1 ms: Driver Manager, Driver 18, transport, or result-processing path.
    • Execution returns quickly but subsequent metadata/fetch calls stall: cursor, metadata, or partially consumed bound-form recordsets.
    • Repeated calls appear only while the form is open: background Access activity is contending or interleaving with the test.

    This is more discriminating than another DAO stopwatch measurement.

    2. Capture Access process stacks and waits simultaneously

    Use Windows Performance Recorder to determine what the Access thread is doing during each 200 ms interval. WPR records ETW events that Windows Performance Analyzer can inspect.^3^

    Run from an elevated terminal:

    wpr -start GeneralProfile -filemode

# Reproduce one fast/slow/fast sequence in Access.

wpr -stop AccessSql2025Latency.etl
wpa.exe AccessSql2025Latency.etl

    In WPA, isolate MSACCESS.EXE and inspect CPU usage, thread activity, waits, disk I/O, and networking over the slow interval. Microsoft’s performance workflow recommends finding the relevant application thread and examining its top CPU and wait stacks.^4^

    Useful distinctions include:

    • stacks in Access/ACE before an ODBC API call;
    • stacks in the ODBC Driver Manager or Driver 18;
    • synchronization waits between Access threads;
    • certificate, authentication, DNS, or network-filter activity;
    • repeated UI/form timer or recordset refresh work.

    3. Add packet timing only if the ODBC call itself is slow

    If the Driver Manager trace places the delay inside an ODBC call, capture client and server network traffic over the same short reproduction. Because Access and SQL Server 2025 are local, Microsoft specifically documents using a packet capture with the Npcap driver for same-machine tracing; SQL Network Analyzer can then process the trace.^5^

    Compare:

    1. Time Access enters the ODBC call.
    2. Time the TDS request is sent.
    3. Time the final response packet arrives.
    4. Time the ODBC call returns.

    That separates pre-send client delay, transport/server-response delay, and post-response driver processing.

    Version and support-case checks

    • Record the exact MSACCESS.EXE, ACE, Driver 18 DLL, Windows, and SQL Server build numbers.
    • If Driver 18 is older than [IP Address], reproduce on a controlled test machine with that release; it is the documented 18.7 Windows version.^6^
    • Supply the minimal database, affected form properties/record sources, VBA timer, ODBC trace, ETL, XE data, and a timestamped fast/slow/fast reproduction to Microsoft Support.
    • The published SQL Server 2025 known-issues list does not currently include this Access/ODBC bound-form pattern.^7^
    • The documented PBKDF2 issue affects SQL Authentication login cost, especially without pooling. It does not explain repeated delays on the same established session.

    FQDN/SPN/Kerberos changes should only be investigated if the capture shows new connections or authentication activity during each delay. A superficially similar Access/ODBC case improved after replacing an IP-based connection with FQDN/port and correcting NTLM fallback, but that case was connection/authentication-related and is not yet a close match for your same-session symptom.^8^

    References

    1. Troubleshoot query performance difference between database application and SSMS
    2. ODBC diagnostics
    3. Windows Performance Recorder
    4. Improve the responsiveness of your Windows app
    5. Consistent SQL Server network connectivity issues
    6. Release Notes for Microsoft ODBC Driver for SQL Server on Windows
    7. SQL Server 2025 Known Issues - SQL Server | Microsoft Learn
    8. Microsoft Access Linked Table To Sql Server Express via ODBC 17 or ODBC 18 Driver - Microsoft Q&A
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. 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.

    EDIT:

    Adding to my answer based on Erland's comment, it seems Access DAO physically closes connections to linked tables when no queries (bound data access objects) are actively using a linked table. A workaround, albeit a kluge, is to keep a persistent connection open with an active non-visible DAO recordset. I haven't tried this VBA code myself (I haven't used Access for 30 years) but it's worth a try at application startup if you must use SQL authentication.

    ' Global variable in a standard module to keep the connection and recordset alive

    Public rsPersistent As DAO.Recordset

    Public Sub OpenPersistentConnection()

    Dim db As DAO.Database

    Set db = CurrentDb

    ' Open a tiny, lightweight table or dummy view to hold the line open

    Set rsPersistent = db.OpenRecordset("SELECT TOP 1 1 FROM MyLinkedTable", dbOpenSnapshot)

    End Sub

    Public Sub ClosePersistentConnection()

    On Error Resume Next

    If Not rsPersistent Is Nothing Then

    rsPersistent.Close

    Set rsPersistent = Nothing

    End If

    End Sub

    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.