На мою думку, SET XACT_ABORT ON став застарілим додаванням BEGIN TRY / BEGIN CATCH у SQL 2k5. Перед блоками виключень у 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, є чистота даних : іноді отримані параметри або дані в таблицях просто невірно, що призводить до повторюваних помилок ключів, помилок референсного обмеження, перевірки помилок обмеження тощо тощо. Зрештою, саме в цьому і полягає роль цих обмежень, якщо ці помилки чистоти даних були б неможливі, і всі вони потрапляли в ділову логіку, обмеження були б усі застарілими (для ефекту додається драматичне перебільшення). Якщо XACT_ABORT увімкнено, усі ці помилки призводять до втрати всієї транзакції, на відміну від можливості блокувати коди виключень, які обробляють виняток витончено. Типовим прикладом є спроба зробити INSERT та повернутися до UPDATE на порушення ПК.