2009-12-04 4 views
2

J'ai un problème assez étrange avec MySQL. Essayer de créer une procédure pour mettre à jour certains champs dans la base de données (le code est ci-dessous).MySQL query browser procedure error code 0

Le problème est avec la ligne actuellement commentée. Il semble que si aucune instruction SELECT n'est exécutée pendant la procédure, le navigateur de requête MySQL retournera un code d'erreur "-1, erreur exécutant une requête SQL".

J'ai essayé la même chose dans HeidiSQL et l'erreur était "impossible de retourner le jeu de résultats". Donc, je suppose que la question est de savoir si je dois toujours sélectionner quelque chose dans la procédure, ou y a-t-il autre chose que j'ai manqué?

La requête fonctionne correctement lorsque le commentaire est supprimé.

DELIMITER/
DROP PROCEDURE IF EXISTS updateFavourites/
CREATE PROCEDURE updateFavourites(quota INT) 
BEGIN 
DECLARE done INT DEFAULT 0; 
DECLARE artist_id,releases INT; 
DECLARE c_artist Cursor FOR 
    SELECT Artist.id_number,COUNT(Artist.id_number) FROM Artist 
    JOIN CD ON CD.is_fronted_by = Artist.id_number 
GROUP BY Artist.id_number; 

DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' 
    SET done=1; 

IF quota > 0 THEN 
    OPEN c_artist; 
    REPEAT 
    FETCH c_artist INTO artist_id,releases; 
     IF NOT done THEN 
     IF releases >= quota THEN 
      UPDATE CD SET CD.rating='favourite' WHERE CD.is_fronted_by = artist_id; 
     END IF; 
    END IF; 
UNTIL done END REPEAT; 
CLOSE c_artist; 
-- SELECT 'Great success'; 
ELSE 
    SELECT CONCAT('\'quota\' must be greater than 0.',' Got (',quota,')'); 
END IF; 

END/
DELIMITER ; 

Voici le SQL pour créer les tables et certaines données:

DROP TABLE IF EXISTS CD; 
DROP TABLE IF EXISTS Artist; 

CREATE TABLE Artist (
id_number INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, 
name VARCHAR(50), 
); 

CREATE TABLE CD (
catalog_no  INTEGER UNSIGNED AUTO_INCREMENT PRIMARY KEY, 
is_fronted_by  INT UNSIGNED, 
rating   ENUM ('favourite','top draw','good','so-so','poor','rubbish'), 
CONSTRAINT fk_CD_Artist FOREIGN KEY (is_fronted_by) REFERENCES Artist(id_number) ON UPDATE  CASCADE 
); 

INSERT INTO Artist VALUES(11,'Artist 1'); 
INSERT INTO Artist VALUES(10,'Artist 2'); 
INSERT INTO CD VALUES (7,11, 'top draw'); 
INSERT INTO CD VALUES (650,11,'good'); 
INSERT INTO CD VALUES (651,11,'good'); 
INSERT INTO CD VALUES (11,10,'favourite'); 
+0

Je regarde le code dans le bloc IF et je vois plusieurs instructions. Puisqu'il existe plusieurs instructions, celles-ci ne devraient-elles pas être enveloppées dans un bloc BEGIN/END? –

+0

Pour autant que je sache non, mais je suis plutôt nouveau pour les procédures. Comment feriez-vous exactement cela? BEGIN OPEN c_artist; ... END ELSE donne une erreur de syntaxe. Envelopper le bloc IF entier aussi bien. –

+0

Quelle version de MySQL utilisez-vous et pouvez-vous ajouter vos définitions de schéma et éventuellement échantillonner des données? – r00fus

Répondre

1

recherche sur Google autour, il y a plusieurs rapports de la même erreur, mais peu d'informations pour résoudre le problème. Il y a même un bug enregistré sur mysql.com mais il semble avoir été abandonné sans être résolu.

Il existe un autre StackOverflow question sur la même erreur, mais il n'est pas non plus résolu. Tout ce que cela signifie est qu'il n'y a pas de jeu de résultats à partir de la requête. En regardant le code source, il semble que parfois un état d'erreur MYX_SQL_ERROR est défini lorsque la requête n'a pas de jeu de résultats. Peut-être que ce n'est pas une conséquence appropriée?

Je remarque que lorsque j'utilise le client de ligne de commande mysql, il ne génère aucune erreur pour l'appel d'un proc qui ne renvoie aucun jeu de résultats.


mise à jour: J'ai essayé de faire revivre ce rapport de bogue MySQL, et pour leur fournir un bon cas de test. Ils ont changé le bug de « pas de commentaires » à « vérifié » - si au moins ils reconnaissent qu'il est un bug dans le navigateur de requête:

[11 Dec 9:18] Sveta Smirnova

Bill,

thank you for the feedback. Verified as described.

Although most likely this only be fixed when MySQL Query Browser functionality is part of MySQL workbench.

Je suppose que la solution consiste à ignorer la -1 erreur, ou pour tester votre procédures stockées dans le client mysql de ligne de commande, où l'erreur ne se produit pas.

Le commentaire suppose que le problème disparaîtra lorsque la fonctionnalité Navigateur de requêtes sera intégrée à MySQL Workbench. Ceci est supposed to happen dans MySQL Workbench 5.2. Je vais télécharger cette version bêta et essayer. MySQL Workbench 5.2 est en version bêta, mais je suppose que l'ingénierie MySQL ne peut pas prédire quand la version bêta deviendra GA. Ce genre de prédictions est assez difficile dans des conditions standard, mais il y a beaucoup d'incertitude supplémentaire quant au sort de MySQL en raison de l'acquisition d'Oracle non résolue.


mise à jour: D'accord, je l'ai essayé MySQL Workbench 5.2.10 beta.J'ai exécuté une procédure stockée comme ceci:

CREATE PROCEDURE FooProc(doquery SMALLINT) 
BEGIN 
    IF doquery THEN 
    SELECT * FROM Foo; 
    END IF; 
END 

Quand je CALL FooProc(0) la réponse est aucun jeu de résultats, et l'état est tout simplement « OK ».

Lorsque I CALL FooProc(1) la réponse est le résultat de SELECT * FROM Foo comme prévu.

Cependant, il existe un autre bug lié aux procédures d'appel. Les procédures peuvent avoir plusieurs ensembles de résultats, il est donc difficile de savoir quand fermer l'instruction lorsque vous exécutez une requête CALL. La conséquence est que MySQL Workbench 5.2 ne le fait pas fermer la déclaration, et si vous essayez de faire une autre requête (soit CALL ou SELECT) il vous donne une erreur:

Commands out of sync; you can't run this command now.

MySQL ne supporte pas les multiples simultanées ouvrir des requêtes. Donc, le dernier doit être fermé avant de pouvoir en commencer un nouveau. Mais il ne ferme pas la requête CALL. Ce bug est également enregistré sur le site MySQL.


Le problème concernant les commandes non synchronisées a été résolu. Ils disent qu'il est corrigé dans MySQL Workbench 5.2.11.

+0

Salut, ouais j'ai trouvé le même rapport de bug sur mysql.com, et quelques threads non résolus dispersés ici et là sur le problème. Donc diriez-vous que c'est un problème avec le client de navigateur de requête? –

+0

Oui; voir ma mise à jour ci-dessus. –

+0

cour. "Commandes non synchronisées": beta est la version bêta – noonex

0

Essayez de mettre BEGIN et blocs END autour des multiples déclarations contenues dans le bloc IF en tant que tel:

IF quota > 0 THEN 
    BEGIN 
     OPEN c_artist; 
     REPEAT 
     FETCH c_artist INTO artist_id,releases; 
     IF NOT done THEN 
      IF releases >= quota THEN 
       UPDATE CD SET CD.rating='favourite' WHERE CD.is_fronted_by = artist_id; 
      END IF; 
     END IF; 
     UNTIL done END REPEAT; 
     CLOSE c_artist; 
    END; 
ELSE 
    SELECT CONCAT('\'quota\' must be greater than 0.',' Got (',quota,')'); 
END IF; 
+0

Cela compile mais produit toujours la même erreur -1. –

2

Le navigateur de requêtes n'est pas destiné à l'exécution de scripts, mais à une seule requête. J'ai essayé votre code en déplaçant le curseur dans chaque requête (sauf DELIMITER) et en appuyant sur Ctrl + Entrée. Il a créé cette procédure stockée sans problème. (juste actualiser le schéma sur la gauche).

Si vous souhaitez créer une procédure, utilisez le menu "Script" -> "Créer une procédure stockée/fonction".

Mais mieux vaut oublier QueryBrowser il n'est pas supporté du tout (et actunally pas utile). Si vous avez un matériel décent et de nombreuses ressources, essayez Workbench 5.2 sinon utilisez SQLyog

+0

Ok, essayé workbench 5.2 bêta. Cela semble bien, alors le problème est mysql query browser et jHeidi. Merci pour votre aide. –