Azure SQL Database has no server-side statement timeout configuration across client drivers

Answer first

Azure SQL Database does not provide a server-side SET STATEMENT_TIMEOUT. Timeout enforcement is client-side only, per driver CommandTimeout / query timeout setting. There is no T-SQL setting that caps statement duration for all clients.

Per-session LOCK_TIMEOUT is also session scoped. With connection pooling or reconnection, the session is new and the previous LOCK_TIMEOUT is not retained unless reapplied on checkout. Client-initiated cancellation can abort a statement without automatically rolling back an open transaction, leaving the session in an active transaction if the app does not explicitly roll back.

Confirmed facts

• No native server-side statement timeout in Azure SQL Database. Timeout is enforced by the driver.
• LOCK_TIMEOUT and other session SET options are lost when a pooled connection is returned to the pool and reused.
• Query Store captures elapsed time and cancellation reason, but does not directly label a client driver timeout.

Likely explanation

The fragmentation you see across ADO.NET, JDBC, ODBC, Python and PHP is expected. Each driver has a different property name and default, and pooling resets session context. Cancellation semantics are driver dependent, so a timeout in one client may surface as a different error in another.

Steps to enforce uniform behavior

1. Centralize timeout value. Pick one timeout in milliseconds and apply it identically in every driver configuration: ADO.NET CommandTimeout, JDBC Statement.setQueryTimeout or connection property, ODBC QueryTimeout, Python pyodbc command timeout, PHP PDO::ATTR_TIMEOUT / SQLSRV driver timeout.
2. Wrap execution in a uniform error handling contract. Catch timeout / cancellation as a distinct class, then explicitly ROLLBACK any open transaction before releasing the connection.
3. Reapply session settings on connection checkout. If you rely on LOCK_TIMEOUT, SET DEADLOCK_PRIORITY etc., re-issue them after acquiring a connection from the pool. Do not assume they persist.
4. Keep transactions short and explicit. Start transaction at logical operation start, commit or rollback before timeout can fire. Use SET XACT_ABORT ON for the session so runtime errors trigger automatic rollback where supported.
5. Add application-level cancellation. Use a driver-agnostic cancellation token with a single timeout source, so the same deadline applies regardless of driver implementation.

Transaction boundaries to absorb cancellation

• Never hold an open transaction across a potentially long-running statement.
• Structure code as try / catch / finally: BEGIN TRAN, execute, COMMIT on success, ROLLBACK on timeout or error, finally release connection.
• Avoid mixing multiple statements in one transaction unless they are atomic and short.

Query Store signal for timeout abandonment

Query Store records start_time, end_time, elapsed_time and a cancel reason. A query that stops early with cancel_reason indicating client-initiated cancellation is a signal, but Query Store alone does not prove the cause was a driver timeout versus an explicit client cancel. Supplemental telemetry is needed for reliable detection.

Assumptions: you are using pooled connections and multiple drivers in production. Uncertainty remains on exact driver property names and defaults, which vary by version. Verification steps: review each driver docs for the correct timeout property and default, enable Query Store and compare elapsed time to configured timeout, and run a controlled sleep query longer than timeout to verify consistent exception behavior across drivers.

One missing diagnostic detail that changes the recommendation: which connection pool implementation and whether you reset session context on checkout. If you are using a pool that preserves session state, the LOCK_TIMEOUT reapply step can be reduced.