Moim zdaniem SET XACT_ABORT ON stał się przestarzały przez dodanie BEGIN TRY / BEGIN CATCH w SQL 2k5. Przed blokami wyjątków w Transact-SQL obsługa błędów była naprawdę trudna, a niezrównoważone procedury były zbyt powszechne (procedury, które miały inny @@ TRANCOUNT na wyjściu w porównaniu z wejściem).
Dzięki dodaniu obsługi wyjątków języka Transact-SQL pisanie poprawnych procedur, które gwarantują prawidłowe zbilansowanie transakcji, jest znacznie łatwiejsze. Na przykład używam tego szablonu do obsługi wyjątków i transakcji zagnieżdżonych :
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
Pozwala mi na pisanie atomowych procedur, które wycofują tylko swoją własną pracę w przypadku naprawialnych błędów.
Jednym z głównych problemów, z jakimi borykają się procedury Transact-SQL, jest czystość danych : czasami otrzymane parametry lub dane w tabelach są po prostu błędne, co skutkuje zduplikowanymi błędami klucza, błędami ograniczeń referencyjnych, błędami ograniczeń sprawdzania i tak dalej. W końcu to właśnie rola tych ograniczeń, jeśli te błędy czystości danych byłyby niemożliwe i wszystkie zostałyby przechwycone przez logikę biznesową, wszystkie ograniczenia byłyby przestarzałe (dramatyczna przesada dodana dla efektu). Jeśli XACT_ABORT jest ON, wszystkie te błędy powodują utratę całej transakcji, w przeciwieństwie do możliwości kodowania bloków wyjątków, które z wdziękiem obsługują wyjątek. Typowym przykładem jest próba wykonania INSERT i powrót do UPDATE w przypadku naruszenia PK.