MySQL transmet le code d'erreur à l'appelant et sur la base de ce code d'erreur, l'appelant est libre de décider s'il veut valider le travail effectué jusqu'à présent (en ignorant l'erreur avec ce INSERT particulier déclaration) ou pour annuler la transaction.
Ceci est différent de PostgreSQL qui interrompt toujours la transaction en cas d'erreur et ce comportement est source de nombreux problèmes.
Mise à jour :
C'est une mauvaise pratique d'utiliser un ROLLBACK inconditionnel à l'intérieur des procédures stockées.
Les procédures stockées sont empilables et les transactions ne le sont pas, donc un ROLLBACK dans une procédure stockée imbriquée reviendra au tout début de la transaction, et non à l'état d'exécution de la procédure stockée.
Si vous souhaitez utiliser des transactions pour restaurer l'état de la base de données en cas d'erreur, utilisez SAVEPOINT constructions et DECLARE HANDLER pour revenir aux points de sauvegarde :
CREATE PROCEDURE prc_work()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK TO sp_prc_work;
SAVEPOINT sp_prc_work;
INSERT …;
INSERT …;
…
END;
L'échec de l'une ou l'autre des insertions annulera toutes les modifications apportées par la procédure et la quittera.
