© Éditions Eyrolles
275
chapitre n° 7
Programmation avancée
Invalidation dans le déclencheur
Une fonctionnalité importante des déclencheurs consiste à pouvoir invalider l’événement qui
a déclenché l’action. En d’autres termes, c’est pouvoir faire dire au déclencheur non à une
insertion, une modification ou à une suppression. Ces cas concernent les déclencheurs lignes
de type BEFORE, puisqu’il faudra vérifier des conditions dans le corps du déclencheur avant
éventuellement d’accepter l’événement.
Dans un déclencheur de type BEFORE :
q
Il est possible de modifier une colonne préfixée de NEW à la condition de détenir le privilège UPDATE associé. Cela signifie que l’on peut changer un enregistrement avant de
l’insérer.
q
La valeur d’une colonne AUTO_INCREMENT préfixée par NEW est 0 (et ne suit pas la
séquence existante). La valeur actualisée de la séquence ne sera effective que lors de
l’insertion.
Dans tout déclencheur (de type BEFORE ou AFTER), une erreur lors de l’exécution et toutes les
instructions du bloc sont invalidées.
Principe
Sans parler de MySQL, l’invalidation dans un déclencheur se traduit en général par le déclenchement d’une exception (qui fait avorter l’instruction LMD), et par le retour d’un message
d’erreur personnalisé.
Les procédures et déclencheurs MySQL ne permettent pour l’instant ni de provoquer une
exception système ni de retourner un code SQL personnalisé.
Il n’est pas non plus possible d’utiliser ROLLBACK dans un déclencheur (ERROR 1422
(HY000): Explicit or implicit commit is not allowed in stored function
or trigger).
Une seule solution, qui n’est pas du tout satisfaisante, comme nous allons le voir, consisterait
à provoquer artificiellement une erreur (mais pas une erreur système, par exemple accéder à
une table inexistante). Il faut une erreur sémantiquement correcte qui pose problème à
l’exécution (NULL dans une clé primaire).
Si vous programmez une erreur système (SELECT d’une table inexistante) elle sera relevée
dans tous les cas d’exécution du déclencheur !
L’inconvénient majeur de cette astuce est que le message d’erreur ne sera jamais explicite, car
il ne sera pas en rapport avec la contrainte qui n’est pas satisfaite dans le déclencheur.
275
chapitre n° 7
Programmation avancée
Invalidation dans le déclencheur
Une fonctionnalité importante des déclencheurs consiste à pouvoir invalider l’événement qui
a déclenché l’action. En d’autres termes, c’est pouvoir faire dire au déclencheur non à une
insertion, une modification ou à une suppression. Ces cas concernent les déclencheurs lignes
de type BEFORE, puisqu’il faudra vérifier des conditions dans le corps du déclencheur avant
éventuellement d’accepter l’événement.
Dans un déclencheur de type BEFORE :
q
Il est possible de modifier une colonne préfixée de NEW à la condition de détenir le privilège UPDATE associé. Cela signifie que l’on peut changer un enregistrement avant de
l’insérer.
q
La valeur d’une colonne AUTO_INCREMENT préfixée par NEW est 0 (et ne suit pas la
séquence existante). La valeur actualisée de la séquence ne sera effective que lors de
l’insertion.
Dans tout déclencheur (de type BEFORE ou AFTER), une erreur lors de l’exécution et toutes les
instructions du bloc sont invalidées.
Principe
Sans parler de MySQL, l’invalidation dans un déclencheur se traduit en général par le déclenchement d’une exception (qui fait avorter l’instruction LMD), et par le retour d’un message
d’erreur personnalisé.
Les procédures et déclencheurs MySQL ne permettent pour l’instant ni de provoquer une
exception système ni de retourner un code SQL personnalisé.
Il n’est pas non plus possible d’utiliser ROLLBACK dans un déclencheur (ERROR 1422
(HY000): Explicit or implicit commit is not allowed in stored function
or trigger).
Une seule solution, qui n’est pas du tout satisfaisante, comme nous allons le voir, consisterait
à provoquer artificiellement une erreur (mais pas une erreur système, par exemple accéder à
une table inexistante). Il faut une erreur sémantiquement correcte qui pose problème à
l’exécution (NULL dans une clé primaire).
Si vous programmez une erreur système (SELECT d’une table inexistante) elle sera relevée
dans tous les cas d’exécution du déclencheur !
L’inconvénient majeur de cette astuce est que le message d’erreur ne sera jamais explicite, car
il ne sera pas en rapport avec la contrainte qui n’est pas satisfaite dans le déclencheur.