私の意見では、SET XACT_ABORT ONは、SQL 2k5にBEGIN TRY / BEGIN CATCHを追加することで廃止されました。Transact-SQLの例外ブロックの前は、エラーを処理するのが本当に難しく、不均衡なプロシージャが一般的でした（出口と入口で異なる@@ TRANCOUNTがあったプロシージャ）。
Transact-SQLの追加により、トランザクションのバランスを適切に保つことが保証されている正しいプロシージャを書くのがはるかに簡単になります。たとえば、例外処理とネストされたトランザクションにこのテンプレートを使用します。
create procedure [usp_my_procedure_name]
as
begin
set nocount on;
declare @trancount int;
set @trancount = @@trancount;
begin try
if @trancount = 0
begin transaction
else
save transaction usp_my_procedure_name;
-- Do the actual work here
lbexit:
if @trancount = 0
commit;
end try
begin catch
declare @error int, @message varchar(4000), @xstate int;
select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
if @xstate = -1
rollback;
if @xstate = 1 and @trancount = 0
rollback
if @xstate = 1 and @trancount > 0
rollback transaction usp_my_procedure_name;
raiserror ('usp_my_procedure_name: %d: %s', 16, 1, @error, @message) ;
end catch
end
go
回復可能なエラーが発生した場合に、自分の作業だけをロールバックするアトミックプロシージャを作成できます。
Transact-SQLプロシージャが直面する主な問題の1つはデータの純度です。受信したパラメーターまたはテーブル内のデータがまったく間違っている場合があり、その結果、重複キーエラー、参照制約エラー、チェック制約エラーなどが発生します。結局のところ、それがまさにこれらの制約の役割です。これらのデータ純度エラーが不可能であり、すべてがビジネスロジックによってキャッチされる場合、制約はすべて廃止されます（劇的な誇張が効果のために追加されます）。XACT_ABORTがONの場合、これらのすべてのエラーにより、例外を適切に処理する例外ブロックをコーディングするのではなく、トランザクション全体が失われます。典型的な例は、INSERTを実行しようとし、PK違反でUPDATEに戻ることです。