Interface ExecuteSQLOptions

Explicit driver handle (pool, client, or transaction). When set, the statement bypasses the ambient transaction — required for teardown/probes after a doomed TX.

Optional description for this SQL operation, used by logging, if logging is supported by the underlying provider

Run on the pool even while an ambient transaction is open, without naming a handle. For reads that are not part of any caller's unit of work — the metadata dataset a background refresh loads — so they never land on the transaction's connection beside its COMMIT. A pool read sees committed data only (#4514).

If true, this statement will not be logged to any logging session

Whether this is a data mutation operation (INSERT/UPDATE/DELETE or SP call that results in any data change)

The statement with its parameter values written in as literals. A provider that supports it logs this in place of the parameterized statement and shows it in error messages.

Run the statement inside a read-only transaction that is always rolled back, for SQL a caller supplied. Writes fail, and any session setting the statement changes (SET, set_config) is undone before the connection goes back to the pool, so it cannot reach a later request. Inside an ambient transaction the statement runs in that transaction as usual. PostgreSQL honours it; SQL Server, whose read queries cannot change session settings, ignores it.

Simple SQL fallback for loggers to emit logging of a simpler SQL statement that doesn't have extra functionality that isn't important for migrations or other logging purposes.

The longest this statement may run, in milliseconds. When it is exceeded the database cancels the statement and the call rejects with a timeout error, so the work stops rather than only the wait. Omitted or 0 means the connection's usual limit applies. It can only shorten that limit, never lengthen it. Ignored inside an ambient transaction, whose statements follow the transaction's own limits.