Version imprimable
Bonjour,
ma question est simple , est ce que oui ou non on peut sur Mysql faire un Update avec un Trigger sur deux tables differentes ex :
END;Code:
2
3
4
5
6
( dans mon ex on peut joindre Table1 et Table 2 )
Merci.
Vu que l'INSERT porte sur Table1, tu ne peux pas avoir NEW.Table2.Field1 !
D'ailleurs, je ne suis pas sûr que la syntaxe NEW.Table1.Field1 soit davantage acceptée ! Il me semble qu'on n'a pas besoin de préfixer la colonne de la table dans ce cas là et c'est peut-être interdit.
Par contre, je ne sais pas si c'est ce que tu cherches à faire, mais j'ose espérer que MySQL accepte de se servir des valeurs fournies à l'INSERT pour modifier ou insérer dans une autre table que celle de l'insert.
Code:
2
3
4
5
6
7
8
j'ai ajouté insert,update.
est ce que ceci est possible?
As-tu testé ?
salut,
comme le présume cinephil, c'est pas comme ça que tu dois faire mais c'est possible...
new réfère la valeur après action dans la table old la valeur avant action...
y a pas de préfixage avec le nom de la table pour ces valeurs donc c'est:
après tu as le droit de faire des insert ou des update sur d'autres tables avec ces valeurs genre:Code:NEW.Field1
Code:UPDATE TABLE2 SET field1 =NEW.Field1;
attention tu as mis un espace entre table et 2 du coup rien que la tu aurais une erreur
Bonsoir,Citation:
Envoyé par alitazichibi
Attention MySQL n'accepte pas plusieurs actions dans un même trigger, tu va devoir créer un trigger pour l'insert, un pour l'update et un autre pour le delete et non faire comme dans oracle, ou autre utilisé IF UPDATING dans ton trigger pour tester l'action de l'utilisateur.
Ensuite dans un trigger tu peut faire un insert, update, delete dans d'autre table,
tu ne doit pas préciser la table quand tu utilise NEW, car le trigger est lancé quand une action est effectué sur un table précise.
attention exia93, il parle de faire des modifications à d'autres tables à partir de ce qui se passe dans le trigger, ça c'est autorisé... pas sur la table sur laquelle porte le trigger car la ça ferait des "références circulaires"
J'ai du mal me faire comprendre ^^ Quand je parle d'action je parle des actions INSERT, UPDATE et DELETE fait sur une table, tu ne peut pas créer un trigger qui va gérer par exemple l'action INSERT et UPDATE il faudra que tu créer deux trigger distinct même si il font la même chose ( par exemple une table de log qui regroupe juste la date de modification d'une table ou autre ),Citation:
Envoyé par ericd69
je ne parlais pas de l'impossibilité de faire par exemple 50 requêtes insert + 20 requêtes update dans un même trigger ou la c'est bien entendu autorisé par MySQL.
j'avais bien compris mais je différenciais juste les 2 situations
on peut même préciser que l'existance de new et old dépend de l'action choisie pour le trigger (insert,update, delete)...
par exemple, un trigger sur insert le old n'a aucun sens, alors que pour delete il en a et new pas du tout... new et old sont des alias dépendant donc du contexte
de même, que tu peux avoir de grosse surprise avec les colonnes ayant un attribut "on cascade" qui ne déclenchera jamais les triggers sur les tables touchées par la propagation... c'est pas toujours le moyen le plus sur de contrôler l'intégrité dans toutes les circonstances
:ccool:
8OCitation:
de même, que tu peux avoir de grosse surprise avec les colonnes ayant un attribut "on cascade" qui ne déclenchera jamais les triggers sur les tables touchées par la propagation...
Encore un gros bug de MySQL ? :aie:
Exia93 à tout compris :), je vous explique mon probleme, j'ai une interface PHP /HTML/JS sur la quelle on a plusieurs champs, ces champs proviennent et inserent des données sur differents tables ex :
Code:
2
3
4
5
6
7
8
9
10
11
X et Y sont deux colonne dans Table1
Z est une colonne de Table2
ma question est la suivante : comment faire marché update Table2.....ca ne marche pas!!!!!
Cdt.
Pourtant ça devrait...Citation:
Envoyé par alitazichibi
As-tu un message d'erreur ?
aucun message d'erreur
Si "ca ne marche pas!!!!!" signifie qu'aucune ligne de table2 n'est modifiée lorsque tu modifies une ligne de la table1 alors ton "WHERE" n'est probablement pas bon.
j'ai testé avec un champ de la table1 et les modif se rappliquent, pour le where il n'ya qu'une seule clé qui lies les deux tables et je l'ai pourtant fais !!!
non c'est documenté et volontaire, je pense que c'est du au fait de vouloir simplifier le mécanisme de vérification du risque de référence circulaire entre trigger... là ils s'assurent que ça ne peut pas arriver même si c'est un peu bourrin...Citation:
Envoyé par CinePhil
mais c'est la même chose en cas de réplication... c'est défendable comme stratégie mais c'est contraignant et faut bien le prendre en compte...
@alitazichibi
comme ce qu'on te dit doit marcher et si tu as pas d'erreur faut que tu nous donne les vraies create des tables, ton trigger réel... car comme le dit fred le problème vient certainement de la sélection de ligne que fait le where de ton update...
Non, cette explication est d'une mauvaise foi absolue et prouve encore que MySQL n'est qu'un brouillon poubelle de base de données même pas relationnel.
En gros tous les bugs de MySQL seraient intentionnels.
En fait la stratégie de MySQL a été dès le départ, "on sait aussi faire ça" et de sortir des modules de code fait à la va vite sans test précis et avec des monstruosité dedans. Citons par exemple le Full text inexploitable, le partitionnement débile, la gestion des nulls nullissime et cette nouveauté qui est d'un crétinisme absolu !
Dans PostGreSQL ceci est parfaitement maitrisé (mais hélas pas toujours parfait - il n'est qu'a voir le partitionnement...), mais il est vrai que PostGreSQL met beaucoup plus de temps et de monde pour satisfaire les exigences sans pour cela introduire des bugs !
A +
là c'est pas un bug c'est documenté et intentionnel...:mouarf:
c'est un choix technique qu'ils ont fait, pas le meilleur certes mais le plus simple pour eux et donc pas forcément pour les utilisateurs...
ils ont fait plein d'autres choix leur simplifiant la vie (interdire les load infile en procédural alors qu'il marchait avant, utf8 limité à 3 octets au lieu de 6, etc...) mais pas celle des utilisateurs...
un bug c'est un comportement inattendu par rapport à celui attendu...:ccool:
Bonsoir,
Je me permets une petite intervention concernant les triggers "multi actions" dans mySQL, car je pense que vous avez fini par embrouiller tout le monde^^
Ce qui n'était pas autorisé dans un trigger (je le dis au passé) dans mysql était le multi traitement conditionnel
par exemple
Code:
2
3
4
5
6
Mais je tenais à vous signaler que ceci est possible sur MySQL depuis la version 5.5, et on peut faire maintenant un seul trigger là où avant il fallait en définir 1 par condition de traitement (on était obligé en gros dans un tel contexte d'appeler une procédure stockée pour faire le traitement à partir d'un seul trigger).
++
oui de manière générique tu peux utiliser toutes les instruction de rupture de code existant dans le procédural...
mais bien sur tu ne peux pas utiliser de code:
- générant un affichage
- engendrant une action sur la table sur laquelle est définie le trigger
- déclenchant le début ou la fin d'une transaction pour une table innodb
les appels de procédures stockées et les exceptions sont autorisés à partir de mysql 5.1.6 (donc les instructions de rupture de code c'était bien avant déjà, d'ailleurs j'ai pas trouvé dans la donc un truc qui l'ai interdit à quelque moment que ce soit, mais j'avoue ne jamais avoir tester des version antérieure à la 5.1)
après le problème des triggers est aussi de comprendre tous les contextes où ils ne seront jamais déclenchés... où celle lié au "definer" qui génèreront des erreurs liées aux droits d'exécution...
enfin au changement de certaines versions l'obligation de les droper avant puis de les recréer sous peine d'avoir de sales surprises! :cry:
le procédural c'est simple!... quoi que... :mouarf:
8OCitation:
enfin au changement de certaines versions l'obligation de les droper avant puis de les recréer sous peine d'avoir de sales surprises!
Encore un bug ?
Manque de tests de non-régression ?
Tu peux préciser ? Quel genre de "sales surprises" ?
Un petit conseil à alitazichibi tout de même
Réservez vos actions de mise à jour ou d'insert dans un trigger UNIQUEMENT sur un AFTER INSERT ou AFTER UPDATE et réservez vos triggers BEFORE INSERT et BEFORE UPDATE UNIQUEMENT pour vos contrôles d'assertion avant tout COMMIT sur vos TRANSACTIONS dans la mesure du possible. Ca vous évitera bien des soucis et des heures de débogage inutiles...
Je pense qu'eric à fait allusion à un souci qui m'est déjà arrivé à savoir, qu'après un upgrade de version faisant intervenir un upgrade dans les tables de définition de triggers, que l'upgrade se fasse mal et que le trigger devienne inopérant (génération d'erreur à l'exécution). Obligation de le supprimer et de le recréer pour que le trigger soit redéfini proprement dans la base...Citation:
Tu peux préciser ? Quel genre de "sales surprises" ?
c'est pas un bug là encore c'est documenté... je peux te les citer si tu veux... 5.0.10, 5.0.16, 5.1.0 ou 5.5.0
si tu passes d'une version antérieure à l'une d'elles tu dois le faire sous peine de ne plus pouvoir droper tes triggers (sauf à droper la table)
en gros c'est à chaque version ou des changement majeur sont faits dans mysql ou la gestion des triggers...
y a bien des chose dans mon cours sur le procédural cinephil, lis le à défaut de le corriger :ccool::mouarf:
sinon oui il vaut mieux bien comprendre l'utilisation de after ou before vu que le trigger est vu comme faisant partie la transaction