Bence SET XACT_ABORT ON, SQL 2k5'e BEGIN TRY / BEGIN CATCH eklenmesi ile geçersiz kılındı. Transact-SQL'de istisna bloklarından önce hataları işlemek gerçekten zordu ve dengesiz prosedürler çok yaygındı (çıkışta girişe kıyasla farklı bir @@ TRANCOUNT olan prosedürler).
Transact-SQL özel durum işleme eklenmesi ile işlemleri düzgün bir şekilde dengelemek için garanti edilen doğru yordamları yazmak çok daha kolaydır. Örneğin, bu şablonu özel durum işleme ve iç içe işlemler için kullanıyorum :
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
Kurtarılabilir hatalar durumunda yalnızca kendi çalışmalarını geri alan atomik prosedürler yazmama izin veriyor.
Transact-SQL yordamlarının karşılaştığı ana sorunlardan biri veri saflığıdır : bazen alınan parametreler veya tablolardaki veriler basit yanlıştır, bu da yinelenen anahtar hataları, referans kısıtlama hataları, kısıtlama hatalarını kontrol eder vb. Sonuçta, bu tam olarak bu kısıtlamaların rolü, eğer bu veri saflığı hataları imkansız ve iş mantığı tarafından yakalansaydı, kısıtlamalar tamamen eski olurdu (etki için dramatik abartı eklendi). XACT_ABORT AÇIK ise, tüm bu hatalar istisnayı zarif bir şekilde işleyen istisna bloklarını kodlayabilmenin aksine tüm işlemin kaybolmasına neden olur. Tipik bir örnek bir INSERT yapmaya ve PK ihlali konusunda bir GÜNCELLEME'ye dönmeye çalışmaktır.