J'ai besoin d'effectuer une MISE À JOUR et une INSÉRER en une seule transaction. Ce code fonctionne bien seul, mais j'aimerais pouvoir l'appeler facilement et transmettre les paramètres requis. Lorsque j'essaie d'imbriquer cette transaction dans une procédure stockée, je rencontre de nombreuses erreurs de syntaxe.
Comment puis-je encapsuler le code suivant afin qu'il puisse être facilement appelé?
BEGIN TRANSACTION AssignUserToTicket
GO
DECLARE @updateAuthor varchar(100)
DECLARE @assignedUser varchar(100)
DECLARE @ticketID bigint
SET @updateAuthor = 'user1'
SET @assignedUser = 'user2'
SET @ticketID = 123456
UPDATE tblTicket SET ticketAssignedUserSamAccountName = @assignedUser WHERE (ticketID = @ticketID);
INSERT INTO [dbo].[tblTicketUpdate]
([ticketID]
,[updateDetail]
,[updateDateTime]
,[userSamAccountName]
,[activity])
VALUES
(@ticketID,
'Assigned ticket to ' + @assignedUser,
GetDate(),
@updateAuthor,
'Assign');
GO
COMMIT TRANSACTION AssignUserToTicket
Réponses:
Vous aimez avoir besoin d'encapsuler ce code dans la
CREATE PROCEDURE ...
syntaxe et de supprimer lesGO
instructions aprèsBEGIN TRANSACTION
et avantCOMMIT TRANSACTION
.Notez également que j'ai ajouté un
TRY...CATCH
bloc d'instructions pour permettre l'exécution d'uneROLLBACK TRANSACTION
instruction en cas d'erreur. Vous avez probablement besoin d'une meilleure gestion des erreurs que cela, mais sans connaître vos besoins, c'est difficile au mieux.Quelques bonnes lectures:
Spécifiez toujours le schéma
Meilleures pratiques pour les procédures stockées
De mauvaises habitudes à éviter
la source
SAVE TRANS
implications de la commande.Si vous souhaitez gérer correctement les procédures stockées imbriquées qui peuvent gérer les transactions (qu'elles soient démarrées à partir de T-SQL ou du code d'application), vous devez suivre le modèle que j'ai décrit dans la réponse suivante:
Sommes-nous tenus de gérer la transaction en code C # ainsi qu'en procédure stockée
Vous remarquerez deux différences par rapport à ce que vous tentez ici:
L'utilisation de l'
RAISERROR
intérieur duCATCH
bloc. Cela fait remonter l'erreur jusqu'au niveau de l'appelant (que ce soit dans la couche de base de données ou d'application) afin qu'une décision puisse être prise concernant le fait qu'une erreur s'est produite.Non
SAVE TRANSACTION
. Je n'ai jamais trouvé de cas pour l'utiliser. Je sais que certaines personnes le préfèrent, mais dans tout ce que j'ai jamais fait à n'importe quel endroit où j'ai travaillé, la notion d'une erreur se produisant dans l'un des niveaux imbriqués impliquait que tout travail déjà effectué était invalide. En utilisant,SAVE TRANSACTION
vous revenez à l'état juste avant l'appel de cette procédure stockée, laissant le processus existant comme autrement valide.Si vous souhaitez plus de détails
SAVE TRANSACTION
, veuillez consulter les informations de cette réponse:Comment restaurer lorsque 3 procédures stockées sont démarrées à partir d'une procédure stockée
Un autre problème avec
SAVE TRANSACTION
est une nuance de son comportement, comme indiqué dans la page MSDN pour SAVE TRANSACTION (soulignement ajouté):Cela signifie que vous devez être très prudent pour donner à chaque point de sauvegarde de chaque procédure stockée un nom unique sur tous les points de sauvegarde de toutes les procédures stockées. Les exemples suivants illustrent ce point.
Ce premier exemple montre ce qui se passe lorsque vous réutilisez le nom du point d'enregistrement; seul le point de sauvegarde de niveau le plus bas est annulé.
Ce deuxième exemple montre ce qui se passe lorsque vous utilisez des noms de point de sauvegarde uniques; le point de sauvegarde du niveau souhaité est annulé.
la source