[TRIGGER] erreur 1442 : le trigger se déclenche mais n'agit pas.

Bonjour,

J'ai un trigger attaché à ma base dont voici le code :

Code:

---

1 2 3 4 5 6

DELIMITER // CREATE TRIGGER nettoyage_caractere AFTER DELETE ON caracteristique FOR EACH ROW BEGIN DELETE FROM nomcaracteristique WHERE OLD.cod_carac NOT IN(SELECT id_caracteristique FROM caracteristique); END// DELIMITER;

---

celui-ci a bien été enregistré par la base (même dans phpMyAdmin)
Or lorsque j'utilise mon script php de destruction d'un item dans la table `caracteristique` le trigger ne fonctionne pas.
Je suis donc allé tester directement dans phpMyAdmin la destruction de l'item concerné et là... :aie:

Voici l'erreur :

Code:

---

#1442 - Can't update table 'caracteristique' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.

---

Donc je ne comprend pas. Apparement il ne peut pas updater tout de suite car le trigger est en train d'agir sur la table. Mais cette action se fait apès la destruction, donc... Est-ce cette confusion qui empèche le trigger d'agir ?

Quelqu'un saurait-il m'aiguiller ?
Merci

Bonjour,
Il s'agit bien d'un problème de simultanéité.
J'ai créé une VUE qui reprend la structure de ma table 'caracteristique' pour que le trigger agisse dessus, et le problème reste inchangé.

Personne n'a des piste à me donner ?? :cry:

Je pensais vraiment pouvoir utiliser des TRIGGER dans mes tables MySQL. Or pour le moment, à part les stocker et ne pas pouvoir m'en servir, je n'ai réussi à rien d'autre. :aie:
Pour le problème précédent, j'ai contourné (pour ceux que ça intéresse) de la manière suivante :
Je crée une PROCEDURE STOCKEE qui détruit les items qu'aurait dû détruire mon TRIGGER, et je l'appelle après ma requête de destruction initiale...
... quasi aucun intérêt, un léger gain de temps du fait de la procédure stockée, c'est tout...

Si quelqu'un a mieux ou trouve une solution au problème ci-dessus, je reste preneur.

Peux-tu expliquer la logique de ce que tu veux faire ?

Bonjour,

J'ai plusieurs tables qui me permettent de gérer des caractéristiques de produits. (2 pour être exact). L'une comprend un identifiant et niveau de profondeur, qui sont les seuls éléments communs aux caractéristiques. L'autre, me permet de les gérer en multilingue (avec un nom, une référence à l'identifiant de la première table, un identifiant langue etc...
Dans une interface d'administration (php5) je gère ces caractéristiques. Et donc je peux les supprimer. Je voulais que lorsque j'envoie une requête DELETE à la première table, il y ait un TRIGGER qui supprime dans le même temps les entrées dans la seconde table, dont les réfrérences à la première viennent d'être détruit.
Prises séparemment toutes mes requêtes fonctionnent.
Le TRIGGER plus haut (à quelques modif prés) est enregistré et se déclenche.
Bien sûr, je pourrais gérer ça avec php et les requêtes, mais d'une part, il me semble qu'il ya un gain au niveau utilisation de la mémoire et des bandes passantes à utiliser un TRIGGER, et d'autre-part je trouve la solution plus élégante et satisfaisante d'un point de vue développement.

Voilà, on peut en discuter bien sûr, mais voici la logique. Ais-je répondu à ta question Antoun ?

Dans ce contexte, pourquoi ne pas utiliser les Foreign Keys et les déclarer en ON DELETE CASCADE ?

Hello qi130 !

Disons que là, je reste sans voix(ça doit être mon qi110 standard...:lol:). J'avoue ne pas connaître ce dont tu me parles. Je vais donc farfouiller de côté.
Merci du tuyaux. Je vous tiens informer des suites des opérations.

De retour...

Très intéressant, et j'en prends bonne note pour plus tard. Malheureusement toutes mes tables actuelles sont en MyISAM. Or visiblement, il les faudrait en InnodB.
Peut-être y a t'il un moyen de les faire toutes (30) changer de format ?

Oui bien sûr on peut basuler de MyISAM à InnoDB. Promis je repose pas une question noob comme celle-ci ! :oops:

Citation:

---

Envoyé par elvan49

Oui bien sûr on peut basuler de MyISAM à InnoDB. Promis je repose pas une question noob comme celle-ci ! :oops:

---

Ce n'en est pas une ;)

Il aurait pu se faire que ton "décor" technique t'interdise l'utilisation du moteur InnoDB...
- l'hébergeur ne veut pas de ce type de table
- InnoDB n'est pas forcément gratuit en exploitation
- etc...

Citation:

---

Envoyé par elvan49

Peut-être y a t'il un moyen de les faire toutes (30) changer de format ?

---

Citation:

---

For example, to convert a table to be an InnoDB table, use this statement:

Code:

---

ALTER TABLE t1 ENGINE = InnoDB;

---

---

Et bien un grand merci pour la solution "Foreign Key".

J'ai viré ma procédure stockée, et créé ma clé et mon index avec ON DELETE CASCADE.
Résultat nickel, et en une seule requête. Donc très satisfaisant.

Merci encore (je vais quand même vérifier que le serveur distant accepte innodB, si ce n'est pas le cas... on changera d'hébergement :mrgreen:)