Use sqlServerSessionId to spot on blocking sessions in Dynamics 365 Business Central 2026 Wave 1
Business Central 2026 Wave 1 (v28) adds sqlServerSessionId to Long Running Queries telemetry (RT0005) and other signals that carry a SQL statement. When a Lock Snapshot (RT0013) shows a blocking SQL session without an AL stack trace because the blocker ran on another service tier, this ID can be traced through RT0005 to find the offending AL session and method.
post Dynamics 365 Business Central tales, myths, legends. And something serious.
Key points
- sqlServerSessionId is now included in all telemetry traces containing sqlStatement values, making it possible to correlate lock timeouts across NSTs
- Lock Snapshot signals (RT0013) cannot provide AL Stack Trace for blocking sessions running on separate NSTs, creating a gap that sqlServerSessionId helps fill
- Investigation workflow involves isolating lock timeouts, filtering lock snapshots for the blocking sqlServerSessionId, then finding Long Running Queries with that same ID
- Concurrency issues can be resolved with ReadIsolation(IsolationLevel::ReadUncommitted) or by optimizing queries using AL Query objects with proper joins and aggregations
AL objects mentioned
As named in the post. A name that matches one object page by exact type and name links to it; the others stay as named.
- codeunit “54001”
- query “54010”
Not found in BC28-30: codeunit “54001”, query “54010”.
Context
- Features: sqlServerSessionId in telemetry, Long Running Queries signal (RT0005), Lock Snapshot signal (RT0013), Lock Timeout signal (RT0012), ReadIsolation levels, AL Query optimization
- Versions: 2026 Wave 1, v28
Source: Duilio Tacconi, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.