I understand the purpose of SET XACT_ABORT command:
When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled back.
When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing. Depending upon the severity of the error, the entire transaction may be rolled back even when SET XACT_ABORT is OFF. OFF is the default setting.
In general, the scenarios where one would want to continue processing a transaction if error would be outnumbered by the scenarios where one would want to rollback the entire transaction if error, because I often hear DBAs and blogs recommending to keep SET XACT_ABORT ON
to avoid running into inconsistent transaction results. I have seen all our stored procedures also have SET XACT_ABORT ON
, as part of the templated-code.
Quesions:
If most of the use cases require
XACT_ABORT
to beON
, what would have lead SQL Server to default it toOFF
? Would defaultingXACT_ABORT
toON
had added any overhead to SQL Server transaction processing?The
SET XACT_ABORT
command affect only the current sessions. I know I can make SSMS default toSET XACT_ABORT ON
fromSSMS > Tools > Options > Query Execution > SQL Server > Advanced
as shown in this image: But this is limited to only for the SQL statements running through SSMS and does not help with stored procedures called through application code/SSIS packages . For those procedures I still have to repeatSET XACT_ABORT ON
in every procedure. Is there any wayXACT_ABORT
can be set toON
at database level? Any other ways I can set theXACT_ABORT
globally and don't have to worry about it every time?