À mon avis, SET XACT_ABORT ON a été rendu obsolète par l'ajout de BEGIN TRY / BEGIN CATCH dans SQL 2k5. Avant les blocages d'exceptions dans Transact-SQL, il était vraiment difficile de gérer les erreurs et les procédures non équilibrées étaient trop courantes (procédures qui avaient un @@ TRANCOUNT différent à la sortie par rapport à l'entrée).
Avec l'ajout de la gestion des exceptions Transact-SQL, il est beaucoup plus facile d'écrire des procédures correctes garantissant un équilibre correct des transactions. Par exemple, j'utilise ce modèle pour la gestion des exceptions et les transactions imbriquées :
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
Cela me permet d'écrire des procédures atomiques qui annulent uniquement leur propre travail en cas d'erreurs récupérables.
L'un des principaux problèmes auxquels les procédures Transact-SQL sont confrontées est la pureté des données : parfois, les paramètres reçus ou les données des tables sont tout simplement faux, ce qui entraîne des erreurs de clé en double, des erreurs de contrainte référentielle, des erreurs de contrainte de vérification, etc. Après tout, c'est exactement le rôle de ces contraintes, si ces erreurs de pureté des données étaient impossibles et toutes prises en compte par la logique métier, les contraintes seraient toutes obsolètes (exagération dramatique ajoutée pour effet). Si XACT_ABORT est activé, toutes ces erreurs entraînent la perte de l'ensemble de la transaction, par opposition à la possibilité de coder des blocs d'exceptions qui gèrent l'exception de manière appropriée. Un exemple typique est d'essayer de faire un INSERT et de revenir à une UPDATE en cas de violation PK.