base de données et l'utilisateur. L'utilisateur n'est donc pas nécessairement conscient des variables utilisateur qui sont définies
ou modifiées dans la procédure. Il pourrait donc définir des variables utilisateur, puis exécuter une procédure et constater que
certaines de ses variables ont été écrasées par la procédure.
Ainsi dans le code suivant :
Code : SQL
SET @var = 'Bonjour';
CALL test_vu();
SELECT @var;
-- Donne 15 !
Un utilisateur inconscient du fait que test_vu() modifie @var pourrait bien y perdre des cheveux !
Un raisonnement similaire peut être tenu pour les autres objets utilisant les blocs d'instructions.
Évitez donc les variables utilisateur dans les blocs quand c'est possible (et nous allons bientôt voir un cas où ce n'est pas
possible).
Utiliser une procédure dans un bloc
CALL nom_procedure(); est une instruction. On peut donc parfaitement exécuter une procédure dans un bloc
d'instructions.
Exemple : la procédure surface_cercle() calcule la surface d'un cercle à partir de son rayon. Elle exécute pour cela la procédure
carre(), qui élève un nombre au carré.
Pour rappel, on calcule la surface d'un cercle avec la formule suivante :
Code : SQL
DELIMITER |
CREATE PROCEDURE carre(INOUT p_nb FLOAT) SET p_nb = p_nb * p_nb|
CREATE PROCEDURE surface_cercle(IN p_rayon FLOAT, OUT p_surface
FLOAT)
BEGIN
CALL carre(p_rayon);
SET p_surface = p_rayon * PI();
END|
DELIMITER ;
CALL surface_cercle(1, @surface);
-- Donne environ pi (3,14...)
SELECT @surface;
CALL surface_cercle(2, @surface);
-- Donne environ 12,57...
SELECT @surface;
Un FLOAT stockant une valeur approchée, il est tout à fait possible (voire probable) que vous obteniez un résultat
différent de celui donné par une calculette.
Transactions et gestion d'erreurs
Un usage classique et utile des gestionnaires d'erreur est l'annulation des transactions en cas d'erreur.
Exemple : la procédure suivante prend en paramètre l'id d'un client, et de deux animaux que le client veut adopter :
Code : SQL
DELIMITER |
Partie 5 : Sécuriser et automatiser ses actions
307/414
www.openclassrooms.com
ou modifiées dans la procédure. Il pourrait donc définir des variables utilisateur, puis exécuter une procédure et constater que
certaines de ses variables ont été écrasées par la procédure.
Ainsi dans le code suivant :
Code : SQL
SET @var = 'Bonjour';
CALL test_vu();
SELECT @var;
-- Donne 15 !
Un utilisateur inconscient du fait que test_vu() modifie @var pourrait bien y perdre des cheveux !
Un raisonnement similaire peut être tenu pour les autres objets utilisant les blocs d'instructions.
Évitez donc les variables utilisateur dans les blocs quand c'est possible (et nous allons bientôt voir un cas où ce n'est pas
possible).
Utiliser une procédure dans un bloc
CALL nom_procedure(); est une instruction. On peut donc parfaitement exécuter une procédure dans un bloc
d'instructions.
Exemple : la procédure surface_cercle() calcule la surface d'un cercle à partir de son rayon. Elle exécute pour cela la procédure
carre(), qui élève un nombre au carré.
Pour rappel, on calcule la surface d'un cercle avec la formule suivante :
Code : SQL
DELIMITER |
CREATE PROCEDURE carre(INOUT p_nb FLOAT) SET p_nb = p_nb * p_nb|
CREATE PROCEDURE surface_cercle(IN p_rayon FLOAT, OUT p_surface
FLOAT)
BEGIN
CALL carre(p_rayon);
SET p_surface = p_rayon * PI();
END|
DELIMITER ;
CALL surface_cercle(1, @surface);
-- Donne environ pi (3,14...)
SELECT @surface;
CALL surface_cercle(2, @surface);
-- Donne environ 12,57...
SELECT @surface;
Un FLOAT stockant une valeur approchée, il est tout à fait possible (voire probable) que vous obteniez un résultat
différent de celui donné par une calculette.
Transactions et gestion d'erreurs
Un usage classique et utile des gestionnaires d'erreur est l'annulation des transactions en cas d'erreur.
Exemple : la procédure suivante prend en paramètre l'id d'un client, et de deux animaux que le client veut adopter :
Code : SQL
DELIMITER |
Partie 5 : Sécuriser et automatiser ses actions
307/414
www.openclassrooms.com