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

Hi Bruno,

Here are a few suggestions that might help.

It may be worth removing the confound first. The 2016/2022 comparison changes three things at once: engine version, database copy, and local vs. remote. If you can, restore the same database on 2022, and also try connecting to 2025 from another machine. If either test is fast, that would narrow things down considerably.

Login cost (PBKDF2) seems less likely here, since you’re on the same session and the requests are fast when no forms are open. Running Dan’s process_login_finish session during a repro would be a quick way to confirm.

Because the delay only appears with bound forms open, I suspect a client-side cause, possibly Access/ACE background-fetching a form’s partially consumed recordset. That would also fit your observation that fully fetching recordsets helped.

Two captures could help confirm this:

XE: capture rpc_completed and sql_batch_completed for all sessions from the client, not only the test session, and look for sp_cursor* activity between your requests.

ODBC trace: check whether the 200 ms passes before SQLExecDirect starts or inside the call.

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