Implements dbt_sqlserver_use_dbt_transactions behavior flag

[axellpadilla]

Adds an opt-in flag that makes dbt's transaction hooks real at the SQL Server level, replacing the current no-op behavior, couldn't find the exact reason this was removed and this stopsome issues we currently have with left over temp tables, dirty reads of empty tables, non-standard behaviors.

What it does

When dbt_sqlserver_use_dbt_transactions: true is set in dbt_project.yml:

• add_begin_query() emits BEGIN TRANSACTION instead of being a no-op
• add_commit_query() emits IF @@TRANCOUNT > 0 COMMIT TRANSACTION instead of being a no-op
• _rollback_handle() emits IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION with error handling matching the base class pattern (fires RollbackFailed event on failure)
• After-commit hooks — the run_hooks macro uses the flag to decide whether hooks run after a real commit or after the previous autocommit-based cleanup

When false (default), behavior is unchanged — begin/commit remain no-ops and each statement is auto-committed by the ODBC driver.

Why opt-in

Enabling real transactions changes the atomicity guarantees and maps to default dbt standard behavior. Without the flag, each SQL statement commits individually — a failure mid-materialization doesn't roll back earlier DDL/DML. With the flag, the entire model run is wrapped in a single T-SQL transaction, and failures roll back everything.

This includes the DML refresh materialization (table_dml_refresh.sql), which has its own explicit BEGIN TRANSACTION for the atomic DELETE+INSERT swap. With the flag on, this nests inside dbt's outer transaction. SQL Server handles this correctly — only the outermost COMMIT actually commits, and a rollback always rolls back all nesting levels — so scratch tables from a partially-executed materialization are cleaned up on failure.

Other changes

• Updated the stale comment in table_dml_refresh.sql to reflect the flag
• Fixed a line length issue in test files
• Added functional tests for table/view/incremental materializations, rollback behavior (with and without the flag), after-commit post-hooks, and recovery after a failed model including xfail temporal variants that will never pass without the flag.
• Added unit tests for add_begin_query/add_commit_query flag gating

Closes #708

[Benjamin-Knight]

The DML work I did has an explicit transaction in it, this probably should only be emitted when this flag is false because when DBT is handling the transaction all it does it create a nested transaction that doesn't add anything to the process.

I can't see the XACT_ABORT work that @joshmarkovic identified as being an issue. If we want DBT to handle transaction should be have this flag emit the XACT_ABORT setting as well?

I think we need a test to cover snapshots as they call adapter.commit in their code path.

[Benjamin-Knight]

I remember someone stating that there are parts of DBT which we may want to not run inside the transaction which is now DBT managed, mostly post hooks, are we planning on shipping this without that resolved? Right now this work would break online and resumable post hook indices that are declared.

[axellpadilla]

@Benjamin-Knight noted the other comments to check. About the parts of dbt, because post hooks that should be resumable, should be stated as not in transaction?, this feature was fixed in #709, and probably nobody is using it, we were doing no transaction practices but because it was not posible, this feature will probably remain optional for a long time (probably only defaulted in v2.1.0?) and recommendations of better future practices should be documented.

[axellpadilla]

@Benjamin-Knight I agree XACT_ABORT is related, but I would treat it as a follow-up. This PR makes dbt transaction boundaries real; XACT_ABORT changes how SQL Server reacts to runtime errors inside those boundaries. If we add it, it should be explicit, tested, and probably scoped/restored carefully, lest better isolate that change. Fixed other comments and did a rework to formalize final state and commets. Thanks.