ORA-00979: not a GROUP BY expression

Je suis en 8.1.7.4. J'ai une requete

Code:

---

1 2 3 4 5 6 7

SELECT TRUNC (date_ent / 10000) ANNEE, LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15) NB_TRUC FROM truc GROUP BY TRUNC (date_ent / 10000) HAVING COUNT (*) > 10 ORDER BY TRUNC (date_ent / 10000);

---

qui fonctionnait tres bien.

Je ne sais pas si cela a un rapport mais comme je suis dans le flou 8O, je vous donnes un maximun d'element.

J'ai arrété l'instance. Changé le CHARACTERE SET de US7ASCII vers WE8ISO8859P1.

J'ai aussi modifié les paramtres d'instance

Code:

---

1 2 3 4 5 6 7

cursor_sharing = FORCE open_cursors = 1024 timed_statistics = TRUE remote_dependencies_mode = SIGNATURE optimizer_index_caching = 90 optimizer_index_caching = 25

---

Et maintenant cette requete me donne une erreur ORA-00979: not a GROUP BY expression. En faisant référence à TRUNC (date_ent / 10000) ANNEE

Si je retire cette partie de la requete ca fonctionne. Une dernière info date_ent est une date stocké dans un NUMBER(8)


Si vous avez des idées....

8O c'est quoi ça ?

Citation:

---

LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15)

---

t'aurais pas des valeurs NULL ?

Code:

---

1 2	LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15)

---

Ca c'est juste du formatage. C'est requete me servent à générer par spool sqlplus une page HTML.

Je ne pense pas cela soit un problème de valeur puisque

Code:

---

1 2 3 4 5 6 7

SELECT LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15) NB_TRUC FROM truc GROUP BY TRUNC (date_ent / 10000) HAVING COUNT (*) > 10 ORDER BY TRUNC (date_ent / 10000);

---

fonctionne correctement mais peut etre que je n'ai pas tout compris

Peut etre y a-t-il un problème de conversion implicite le TRUNC pouvant être appliqué à un nombre et à une date...

Essaye de faire plutot TRUNC(date_ent/10000 , 0) pour voir...

Merci,

C'est un site distant, je ne peux pas tester tout de suite. Je le ferais demain en attendant je ne comprends pas parce que TRUNC (date_ent / 10000) est ecrit de manière identique entre le SELECT et le GROUP BY. Si il y a des conversions implicites elles devraient etre identiques. Non ?

Et aussi pcq j'ai testé la requete

Code:

---

1 2 3 4 5 6 7

SELECT date_ent / 10000 ANNEE, LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15) NB_TRUC FROM truc GROUP BY date_ent / 10000 HAVING COUNT (*) > 10 ORDER BY date_ent / 10000;

---

par contre sans la division ca fonctionne

Code:

---

1 2 3 4 5 6 7

SELECT date_ent ANNEE, LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15) NB_TRUC FROM truc GROUP BY date_ent HAVING COUNT (*) > 10 ORDER BY date_ent;

---

Je pensais que peut etre oracle pouvait tomber sur un null en début de select qui lui faisait basculer la fonction TRUNC en mode "DATE"... mais ton dernier exemple me rend pessimiste sur cette hypothèse... :? On dirait plutot que le soucis viens du passage par le type réel (engendré par la division)

Par contre, je crois que tu peux contourner le problème en faisant autrement.
Remplace "TRUNC (date_ent / 10000)" par "TRUNC (date_ent, -4) /10000" dans ton select, et il me semble que tu pourras faire à ce moment là un group by "TRUNC (date_ent, -4) " simplement.

:marteau:

J'ai finalement pas resisté a tester tout de suite tes propositions et..... non. Ni l'une ni l'autre ne passe :pleure:

J'ai fais en plus le test avec TRUNC(date_env) qui lui passe mais bien sur ne fait pas ce que je veux fonctionnellement ! ! !

Encore merci de votre aide

Et en faisant simplement un TRUNC (date_ent, -4) juste pour tester ?

Sinon tu peux tenter de faire très laid en passant par un substr :

substr (date_ent,1,length(date_ent) - 4)

(j'ai limite honte de proposer des solution pareilles... :aie: )

salut !

La requete est correcte, essaie le code ci-dessous dans toad, il va donner le resultat que tu souhaites:

SELECT TRUNC(:dt_ent/10000 ) ANNEE,
LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15) NB_TRUC
FROM dual
GROUP BY TRUNC(:dt_ent /10000)
HAVING COUNT (*) > 0
ORDER BY TRUNC(:dt_ent/10000 )

remi4444 J'ai essayé toutes tes idées et cela ne marche pas.... Dommage. J'ai toujours ce message idiot ! !

salim11 Oui ton test avec DUAL fonctionne mais par contre cela ne donne pas du tout le résultat que je souhaite. Puisque je n'ai plus les information s de ma table.

Bon, je crois que si je trouves un peut de temps je vais poster ça au support Oracle mais comme c'est une 8.1.7.4 il ne sont pas toujours très réactif

tu devrais essayer de mettre le paramètre cursor_sharing à EXACT, on sais jamais qu'oracle se mette la zone tout seul en réécrivant la requête...

Bonjour,

A la lecture de vos tests, une idée me vient pour éviter la division dans le ORDER BY...

As-tu essayer cette syntaxe ? (Désolé je n'ai pas pris le temps de tester : je n'ai qu'une base 9i sous la main)

Code:

---

1 2 3 4 5 6 7

SELECT TRUNC (date_ent / 10000) ANNEE, LPAD(TO_CHAR(COUNT (*) , '9G999G999G999'),15) NB_TRUC FROM truc GROUP BY TRUNC (date_ent / 10000) HAVING COUNT (*) > 10 ORDER BY 1

---

C'est vrai que la situation semble bizarre...

Désolé c'est un site distant, je n'ai pas pu retester avant....

Citation:

---

Envoyé par cquilgars

Bonjour,
A la lecture de vos tests, une idée me vient pour éviter la division dans le ORDER BY...

---

:yaisse:

Je ne comprends toujours pas pourquoi puisque cette requete fonctionnait avant et qu'elle fonctionne toujours sur d'autres bases avec la division. Mais c'est bien ca la solution :

Remplacer le

Code:

---

ORDER BY TRUNC (date_ent / 10000);

---

par

Code:

---

ORDER BY 1;

---

Il faut quand meme avouer que le message d'erreur n'est pas tres explicite.

En tout cas un grand :merci: à tous

Toujours heureux de donner un coup de main à la communauté (qui me le rend bien d'ailleurs :oops: )

J'ai simplement triché avec le bug. Cette syntaxe a l'avantage de s'assurer que le ORDER BY sera basé sur les valeurs restituées dans le SELECT sans expliciter la formule éventuelle (Elle est aussi faite pour les faineants ;) )
Attention, un tel ORDER BY est souvent plus couteux : Un ORDER BY sur une formule exploitant une colonne indexée ne sera pas aussi rapide que l'ORDER BY sur la colonne uniquement... Il faut préférer la 2ème solution... Surtout, si cela donne le même résultat !!! :mouarf: en terme de résultat d'ordonnancement (j'entends...)

Je parle de bug car je suis entièrement d'accord : la situation n'est pas normale.