Erreur MySQL 2014 - Commandes désynchronisées - lors de la tentative d'appel de procédures stockées consécutives

Question

J'ai une configuration de table MySQL hiérarchique utilisant le modèle Ensemble imbriqué. J'ai créé un proc stocké qui me permet de supprimer une organisation.

Lorsque je tente de faire des appels consécutifs à la procédure stockée, je reçois l'erreur suivante se référant à la deuxième commande CALL:

2014 - Commandes de synchronisation; vous ne pouvez pas exécuter cette commande maintenant

Voici le SQL que je suis en cours d'exécution:

SELECT @id := id, 
     @parent_id := parent_id 
    FROM organization 
WHERE name = 'TESTDEAL'; 

CALL deleteOrg(@id); 
CALL deleteOrg(@parent_id); 

Et voici ma procédure stockée:

DELIMITER $$ 

CREATE PROCEDURE deleteOrg(IN IN_ID INT) 

MODIFIES SQL DATA 

BEGIN 

    START TRANSACTION; 

    SELECT @org_id := id, 
      @myLeft := lft, 
      @myRight := rgt, 
      @myWidth := rgt - lft + 1 
     FROM organization 
    WHERE id = IN_ID; 

    # delete statements for removing roles and other dependencies 

    DELETE FROM organization 
    WHERE id = @org_id; 

    UPDATE organization 
     SET rgt = rgt - @myWidth 
    WHERE rgt > @myRight; 

    UPDATE organization 
     SET lft = lft - @myWidth 
    WHERE lft > @myRight; 

    COMMIT; 

END; 
$$ 

DELIMITER ; 

Pourquoi la deuxième commande manquerais ? Est-ce que MySQL essaie d'exécuter la deuxième commande CALL avant que la première ait été validée? Y a-t-il un moyen de forcer le premier à s'exécuter complètement avant d'appeler le second?

EDIT: table organisation utilise InnoDB

EDIT: J'ai essayé de retirer START TRANSACTION; et COMMIT; mais rencontre toujours la même erreur

Answer 1

L'erreur semble uniquement se produire lors de l'importation d'un script SQL à partir de phpMyAdmin. L'importation du script à partir de la ligne de commande ou à l'aide de la ligne de commande n'entraîne pas d'erreur. Je suppose que cette erreur a à voir avec phpMyAdmin et non avec MySQL. (J'ai également vu d'autres comportements étranges de phpMyAdmin concernant les procédures stockées - J'utilise phpMyAdmin v3.3.2)

Answer 2

Je suppose que cela pourrait avoir quelque chose à voir avec la façon dont vous attribuez vos variables.

Mon conseil est de déclarer les variables locales à l'intérieur de votre procédure, et de les affecter en utilisant SELECT...INTO. C'est une bonne pratique en général, et peut vous aider avec votre problème.

Voici ce que votre procédure ressemblerait à ceci:

DELIMITER $$ 

DROP PROCEDURE IF EXISTS deleteOrg $$ 

CREATE PROCEDURE deleteOrg(IN IN_ID INT) 

MODIFIES SQL DATA 

BEGIN 
    DECLARE V_ORG_ID INT; 
    DECLARE V_MY_LEFT INT; 
    DECLARE V_MY_RIGHT INT; 
    DECLARE V_MY_WIDTH INT; 

    START TRANSACTION; 

    SELECT id, 
      lft, 
      rgt, 
      rgt - lft + 1 
     into V_ORG_ID, 
      V_MY_LEFT, 
      V_MY_RIGHT, 
      V_MY_WIDTH 
     FROM organization 
    WHERE id = IN_ID; 

    -- delete statements for removing roles and other dependencies 

    DELETE FROM organization 
    WHERE id = V_ORG_ID; 

    UPDATE organization 
     SET rgt = rgt - V_MY_WIDTH 
    WHERE rgt > V_MY_RIGHT; 

    UPDATE organization 
     SET lft = lft - V_MY_WIDTH 
    WHERE lft > V_MY_LEFT; 

COMMIT; 

END; 
$$ 

DELIMITER ; 

Answer 3

Je cherche la réponse aussi, autant que je sache, il est lié au recordset retourné par le premier SP. Vous devez "lire" le jeu d'enregistrements pour le vider, puis créer un nouvel appel.