Trigger sur deux tables

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 :

Code:

---

1 2 3 4 5 6

CREATE TRIGGER TriA BEFORE insert ON Table1 FOR EACH ROW begin DECLARE a date; SET NEW.Table1.Field1 = ..... SET NEW.Table2.Field1 = .....

---

END;

( 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:

---

1 2 3 4 5 6 7 8

CREATE TRIGGER TriA BEFORE insert,update ON Table1 FOR EACH ROW begin DECLARE a date; SET NEW.Table1.Field1 = ..... Update table 2 set field1 = ....etc   END;

---

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:

Code:

---

NEW.Field1

---

après tu as le droit de faire des insert ou des update sur d'autres tables avec ces valeurs genre:

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

Citation:

---

Envoyé par alitazichibi

Code:

---

1 2 3 4 5 6 7 8

CREATE TRIGGER TriA BEFORE insert,update ON Table1 FOR EACH ROW begin DECLARE a date; SET NEW.Table1.Field1 = ..... Update table 2 set field1 = ....etc   END;

---

j'ai ajouté insert,update.


est ce que ceci est possible?

---

Bonsoir,

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"

Citation:

---

Envoyé par ericd69

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 ),

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:

Citation:

---

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...

---

8O
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:

---

1 2 3 4 5 6 7 8 9 10 11

DROP TRIGGER IF EXISTS Tri; CREATE TRIGGER Tri BEFORE update ON Table1 FOR EACH ROW begin   SET NEW.X = 5; SET NEW.y = 10;   Update Table2 set Z = '2012-11-30' where .....; END;

---

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.

Citation:

---

Envoyé par alitazichibi

ma question est la suivante : comment faire marcher update Table2.....ca ne marche pas!!!!!

---

Pourtant ça devrait...
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 !!!

Citation:

---

Envoyé par CinePhil

8O
Encore un gros bug de MySQL ? :aie:

---

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...
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:

---

1 2 3 4 5 6

IF NEW.field1=1 THEN UPDATE autretable SET fieldx=NEW.field1 WHERE ... ELSE IF NEW.field1=2 THEN UPDATE autretable SET fieldy=NEW.field1 WHERE... END IF;

---

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: