En mi opinión, SET XACT_ABORT ON quedó obsoleto al agregar BEGIN TRY / BEGIN CATCH en SQL 2k5. Antes de los bloques de excepción en Transact-SQL, era realmente difícil manejar los errores y los procedimientos desequilibrados eran demasiado comunes (los procedimientos que tenían un @@ TRANCOUNT diferente en la salida en comparación con la entrada).
Con la adición del manejo de excepciones Transact-SQL es mucho más fácil escribir procedimientos correctos que garanticen un equilibrio adecuado de las transacciones. Por ejemplo, uso esta plantilla para el manejo de excepciones y transacciones anidadas :
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
Me permite escribir procedimientos atómicos que revierten solo su propio trabajo en caso de errores recuperables.
Uno de los principales problemas que enfrentan los procedimientos de Transact-SQL es la pureza de los datos : a veces los parámetros recibidos o los datos en las tablas son simplemente incorrectos, lo que resulta en errores de clave duplicados, errores de restricción de referencia, errores de restricción de verificación y así sucesivamente. Después de todo, ese es exactamente el papel de estas restricciones, si estos errores de pureza de datos fueran imposibles y todos atrapados por la lógica del negocio, las restricciones serían completamente obsoletas (se agrega una exageración dramática para que tenga efecto). Si XACT_ABORT está ENCENDIDO, todos estos errores dan como resultado la pérdida de toda la transacción, en lugar de poder codificar bloques de excepción que manejan la excepción con gracia. Un ejemplo típico es tratar de hacer una INSERTAR y volver a una ACTUALIZACIÓN en violación de PK.