Précédent   Forum des professionnels en informatique > Bases de données > Firebird > SQL
SQL Forum d'entraide sur le SQL pour Firebird
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 30/05/2005, 10h47   #1
Membre régulier
 
Inscription : février 2005
Messages : 100
Détails du profil
Informations forums :
Inscription : février 2005
Messages : 100
Points : 88
Points : 88
Par défaut pb : multiple rows in singleton select

J'ai rencontré une erreur louche que j'ai trouvée dans mon code SQL d'une de mes procédures stockées et qui est le suivant :

Code :
1
2
3
4
5
6
 
SELECT SUM(PV), numcli, ref_pointrep, Tarif
    FROM TICKET
    WHERE ref_pointfact = :ref_pointfact_input
    GROUP BY ref_pointfact, numcli,ref_pointrep, Tarif
    INTO :Total, :numcli_insert, :ref_pointrep_insert, :Tarif_insert;
Or celui-ci semble afficher l'erreur suivante.

Code :
1
2
3
4
 
multiple rows IN singleton SELECT
.
multiple rows IN singleton SELECT.
Ce qui n'est pas très logique puisque la requête ne peut retourner qu'une seule ligne. Je l'ai d'ailleurs testée isolément et là pas d'erreur.



Citation:
Si java bien, c'est javabeans
sillycoder est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/05/2005, 11h22   #2
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
Par défaut Re: pb : multiple rows in singleton select

Citation:
Envoyé par sillycoder
J'ai rencontré une erreur louche que j'ai trouvée dans mon code SQL d'une de mes procédures stockées et qui est le suivant :

Code :
1
2
3
4
5
6
 
SELECT SUM(PV), numcli, ref_pointrep, Tarif
    FROM TICKET
    WHERE ref_pointfact = :ref_pointfact_input
    GROUP BY ref_pointfact, numcli,ref_pointrep, Tarif
    INTO :Total, :numcli_insert, :ref_pointrep_insert, :Tarif_insert;
Or celui-ci semble afficher l'erreur suivante.

Code :
1
2
3
4
 
multiple rows IN singleton SELECT
.
multiple rows IN singleton SELECT.
Ce qui n'est pas très logique puisque la requête ne peut retourner qu'une seule ligne. Je l'ai d'ailleurs testée isolément et là pas d'erreur.
Non cette requete peut renvoyer plusieurs lignes.
Ce n'est pas parce que vous faites un group by que ca renvoie une seule ligne et heureusement d'ailleurs.
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/05/2005, 11h44   #3
Membre régulier
 
Inscription : février 2005
Messages : 100
Détails du profil
Informations forums :
Inscription : février 2005
Messages : 100
Points : 88
Points : 88
Je veux bien...
Mais étant donné le contenu de la base et les valeurs de retour observées de mes yeux (avec le test en dehors de la procédure stockée)...
Normalement, ça n'en retourne qu'une.
sillycoder est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/05/2005, 13h02   #4
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
Normalement c'est bien là le problème... Normalement
Le jours où Anormalement vous aurez des données supplémentaires qui font que vous avez deux lignes au lieux d'une comment le système devra réagir ???

Je veux bien que vous mettiez des controles en amons qui feront que vous aurez toujours une seule ligne, celà Firebird ou Interbase ne peux le deviner. Il vous dit que votre ordre SQL indépendamment des données que vous avez actuellement (car les données sont sencées évoluer) renvoie plusieurs lignes et que vous l'utilisez comme s'il n'en renvoyait qu'une. C'est normal que celà lui pose un problème.

Je ne vois pas en quoi utilisez une boucle FOR vous pose problème. Actuellement votre boucle ne renvera qu'un enregistrement.
Celà vous permet en plus de déterminer le comportement que doit avoir votre programme en cas ou il en renverait plusieurs ( les ignorer ? les traiter ?)
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/05/2005, 14h14   #5
Membre régulier
 
Inscription : février 2005
Messages : 100
Détails du profil
Informations forums :
Inscription : février 2005
Messages : 100
Points : 88
Points : 88
Justement, j'ai commencé en utilisant une boucle FOR mais j'avais la même erreur qui s'affichait:

Code :
1
2
3
4
5
 
FOR SELECT ... FROM .... INTO ... do
begin
   ici j'incrémentais dans une variable temporaire
end
Alors cela ne m'aide pas vraiment de me dire de faire quelque chose que j'ai déjà essayé.
sillycoder est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/05/2005, 14h22   #6
Membre régulier
 
Inscription : février 2005
Messages : 100
Détails du profil
Informations forums :
Inscription : février 2005
Messages : 100
Points : 88
Points : 88
J'ai repris l'ancienne version de mon code avec la boucle for et ai enfin trouvé la solution. Le problème était tout bêtement dû au nom d'une de mes variables... Trop la honte!!

Merci pour l'aide !
sillycoder est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 12/06/2005, 16h35   #7
Membre éclairé
 
Inscription : décembre 2004
Messages : 379
Détails du profil
Informations forums :
Inscription : décembre 2004
Messages : 379
Points : 304
Points : 304
comme épilogue au problème, voici une solution qui retourne à coup sûr un enregistrement unique, c'est juste un bout de requête qui ne résoud pas tous les problèmes, mais qui fonctionne parfaitement:
Code :
1
2
3
4
SELECT * FROM EMPLOYEE T1
WHERE T1.JOB_COUNTRY = 'USA'
  AND RDB$DB_KEY = ( SELECT MIN( T2.RDB$DB_KEY ) FROM EMPLOYEE T2
                     WHERE T2.JOB_COUNTRY = T1.JOB_COUNTRY )
dans cet exemple, la requête retourne le 1er employé "usa" au lieu de "min", "max" ou tout autre moyen qui isole à coup sûr un unique enregistrement.

ne pas oublier de "lier" le "sous-select" avec les mêmes champs qui isoles les données de la requête principale.
jean-jacques varvenne est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 12h08.


 
 
 
 
Partenaires

Hébergement Web