Dynamic SQL Error SQL error code = -104 invalid column refer

par **zeus** » 11 juil. 2006, 12:48

Non, faut pas le prendre à cet extrème.

Il y aura des gens pour t'aider, je n'en doute pas. Ce que je te reproche, c'est de nous demander de te répondre parce que ta direction te pousse au c**.

Je peut comprendre que tu soit pressé mais nous ne pouvons pas forcément prendre du temps pour te dépanner

par **cool head** » 11 juil. 2006, 12:43

ok sorry.
je ne pensais pas mettre fait comprendre ainsi.
Merci de supprimer ce topic, je vais me débrouiller.

Sincèrement.

par **zeus** » 11 juil. 2006, 12:27

Excuse moi par avance, mais nous ne sommes pas une société de service.

Je te rappelle que si ta société t'as engagé, c'est pour TES compétences, pas les notres.

Je suis sûr qu'il y aura du monde pour t'aider mais ce genre de remarques sont, en plus d'être inutile, vexante.

C'est toi qui est payé, pas nous. (je considère la formation en stage comme un salaire)

par **coolhead** » 11 juil. 2006, 09:43

Bonjour,

Personnes ne peut m'aider ?

car la ma direction me demande quand est ce que ça fonctionnera et je suis un peu à la bourre sur le sujet .

http://www.phpfrance.com/forums/voir_su ... -asc-0.php

par **coolhead** » 15 juin 2006, 10:39

En effet je n'avais pas pensé à ça.
En fait le "CODE_GROUPE" doit toujours être le même.

Mais là où je n'avais pas prévu el clash, c'est pour "CODE_MOTIF_ABS" qui est une valeur "O" ou "N" me permettant de faire le différence entre les abscences justifié et les les absences non-justifié.

Je ne peux donc pas créer une seule requete qui me remonte avec "NB_CRENEAU" la somme d'absence et y ajouter deux champs qui serait "heures_just" et "heures_non_just" dans lesquel je metterait la somme de "NB_CRENEAU" ou "CODE_MOTIF_ABS" = "O" et l'autre avec la somme de "NB_CRENEAU" ou "CODE_MOTIF_ABS" = "N".

Ok j'abandonne.
En plus le "CODE_MOTIF_ABS" n'est pas vraiment OUI ou NON mais uen valeur à lire dans une autre tables ayant un champ "ABS_JUSTIFIEE" qui peut être à "O" ou "N".

En fait je peux pas abandonner car je ne trouve pas d'autres solutions qui me permettent d'avoir mon résultat à l'écran.
A savoir la liste des jeunes avec leur groupe, et le cumul d'abscence.

par **Hubert Roksor** » 13 juin 2006, 15:46

Simplement parce que oracle retourne tout les champs en majuscule

Ah, ceci explique cela

par **zeus** » 13 juin 2006, 15:43

C'est une habitude que je vois essentiellement chez ceux qui travaillent sur Oracle, est-ce que quelqu'un sait pourquoi ?

Simplement parce que oracle retourne tout les champs en majuscule donc depuis n'importe quel visualiseur de BdD, tu as les noms des champs en majuscule.

Et comme on a tendance a copier ce qu'on voit, on copie en majuscule

Il n'y a que dans mes requetes PHP (qui vont rester en dur) que je met que les instructions SQL en majuscule pour des raisons de lisibilité

par **coolhead** » 13 juin 2006, 15:35

En effet je n'avais pas pensé à ça.
En fait le "CODE_GROUPE" doit toujours être le même.

Mais là où je n'avais pas prévu el clash, c'est pour "CODE_MOTIF_ABS" qui est une valeur "O" ou "N" me permettant de faire le différence entre les abscences justifié et les les absences non-justifié.

Je ne peux donc pas créer une seule requete qui me remonte avec "NB_CRENEAU" la somme d'absence et y ajouter deux champs qui serait "heures_just" et "heures_non_just" dans lesquel je metterait la somme de "NB_CRENEAU" ou "CODE_MOTIF_ABS" = "O" et l'autre avec la somme de "NB_CRENEAU" ou "CODE_MOTIF_ABS" = "N".

Ok j'abandonne.
En plus le "CODE_MOTIF_ABS" n'est pas vraiment OUI ou NON mais uen valeur à lire dans une autre tables ayant un champ "ABS_JUSTIFIEE" qui peut être à "O" ou "N".

par **Hubert Roksor** » 13 juin 2006, 15:28

Le problème c'est que plusieurs valeurs de CODE_GROUPE ou CODE_MOTIF_ABS peuvent exister dans chaque groupe, quelle valeur utiliser alors ? si tu les veux toutes je ne vois pas d'autre moyen que de les ajouter dans le GROUP BY, auquel cas la valeur de "heures" s'en verra modifiée. Ou alors tu mets la requête actuelle dans une table dérivée (ou "vue temporaire") et tu fais une jointure sur la table d'absences

Code : Tout sélectionner

    SELECT tmp.CODE_JEUNE, tmp.NOM_JEUNE, tmp.PRENOM_JEUNE, tmp.heures, abs.CODE_GROUP, abs.CODE_MOTIF_ABS
      FROM (

                SELECT j.CODE_JEUNE, j.NOM_JEUNE, j.PRENOM_JEUNE, SUM(a.NB_CRENEAU) AS heures 
                  FROM JEUNE j
            INNER JOIN ABSENCE_CONSTATEE a ON a.CODE_JEUNE = j.CODE_JEUNE
                 WHERE j.CODE_JEUNE < 10
              GROUP BY j.CODE_JEUNE, j.NOM_JEUNE, j.PRENOM_JEUNE

           ) AS tmp
INNER JOIN ABSENCE_CONSTATEE abs ON abs.CODE_JEUNE = tmp.CODE_JEUNE

moi et toi on parle de standard SQL mais les autres parlent de spécificité de SGBD

Malheureusement, il y a un moment où il faut prendre en compte les réalités du monde qui nous entoure. Il n'est pas toujours possible de programmer avec des œillères et suivre aveuglément les standards. Je suis le premier à réclamer un plus grand respect des standards, mais il faut se rendre à l'évidence : à la fin, on programme toujours pour une SGBD particulier. En tout cas, jusqu'à ce que l'ISO développe son propre logiciel ou que Fabian Pascal frotte une lampe à génie.

par **sadeq** » 13 juin 2006, 15:22

Puisque Ibase respecte donc le standard du Group by, tu ne peux que t'y incliner cher ami.
Ta requête devient :

$Sql          = "SELECT j.CODE_JEUNE, j.NOM_JEUNE, j.PRENOM_JEUNE, 
a.CODE_GROUPE, a.CODE_MOTIF_ABS, SUM(a.NB_CRENEAU) AS heures 
FROM JEUNE j 
INNER JOIN  ABSENCE_CONSTATEE a  ON a.CODE_JEUNE = j.CODE_JEUNE 
WHERE j.CODE_JEUNE < 10 
GROUP BY  j.CODE_JEUNE, j.NOM_JEUNE, j.PRENOM_JEUNE, a.CODE_GROUPE, a.CODE_MOTIF_ABS";

ce qui est tout à fait logique, puisque cette requête regroupe le résultat par jeune et par code_groupe et motif avant de calculer la somme de nb_creneau

par **coolhead** » 13 juin 2006, 14:54

Pour ma part je suis en INTERBASE et les champs sont bien en majuscule sous IB.

Par contre par rapport à ma question, bien évidement je ne souhaite pas intégrer les champs supplémentaires "CODE_GROUPE", "CODE_MOTIF_ABS" dans le GROUP BY mais je veux pouvoir les lire par la suite et donc les avoir dans le SELECT.

Je en comprends pas pourquoi je ne peux partir de :

$Sql          = "SELECT j.CODE_JEUNE, j.NOM_JEUNE, j.PRENOM_JEUNE, 
SUM(a.NB_CRENEAU) AS heures 
FROM JEUNE j 
INNER JOIN  ABSENCE_CONSTATEE a  ON a.CODE_JEUNE = j.CODE_JEUNE 
WHERE j.CODE_JEUNE < 10 
GROUP BY  j.CODE_JEUNE, j.NOM_JEUNE, j.PRENOM_JEUNE";

et ajouter ", a.CODE_GROUPE, a.CODE_MOTIF_ABS" dans le SELECT pour les lire.

par **Invité** » 13 juin 2006, 14:41

Je trouve ça extremement bizarre vu qu'on touche à la nomr SQL/ANSI quand même

Quelle est la requete que tu as essayé ?

effectivement zeus, moi et toi on parle de standard SQL mais les autres parlent de spécificité de SGBD.

De toutes façons, les erreurs ne pourraient se résoudre que si on se conforme d'abord aux normes et qu'on comprenne les notions de base et par la suite optimiser le comment-faire.

Par exemple, pour que le regroupement soit cohérent, il faut :
1. au moins une table centrale où le calcul doit être effectué sur un lot d'enregistrements ayant des caractères communs (doublons de valeurs de champs) tel que des index avec doublons ou des clés étrangères

2. si le regroupement doit s'étendre sur plusieurs tables, les jointures entre la table centrale de travail et les autres doivent être définies dans un ordre logique

3. La clause select décide de la structure du résultat (liste de champs + calculs)

4. La clause From définit la source principale du travail ainsi que les sources annexes qui lui sont liées

5. la clause group by définit l'ordre de critères de regroupement (ordre des champs définits dans le select sur lequel le tri des lignes sera effectué pour traiter les calculs)
L'orde des champs dans le group by n'est pas forcement le même de celui du select
La clause Having définit les critères de filtrage au moment du regroupement. Cette clause est annexée au Group By et remplace le Where du select.

par **Hubert Roksor** » 13 juin 2006, 14:31

À l'origine je ne voulais poster que pour conseiller à coolhead d'éviter de tout écrire en majuscule, et en particulier le nom des champs PARCE QUE C'EST SUPER DIFFICILE À LIRE ET ON NE VOIT OÙ SONT LES MOTS IMPORTANTS. C'est une habitude que je vois essentiellement chez ceux qui travaillent sur Oracle, est-ce que quelqu'un sait pourquoi ?

À part ça, je suis nul niveau Oracle, mais d'après ce que je me rappelle la base est assez laxiste face aux "GROUP BY" partiels (où tous les champs SELECT ne sont pas couverts par le GROUP BY ou une fonction d'aggrégation) et ne déclenchera pas d'erreur si le résultat est identique avec ou sans un GROUP BY complet. Autrement dit, si la requête n'est pas bonne mais que ça n'affecte pas le résultat alors rien ne se passe. Je ne l'ai pas vérifié, c'est juste ce que je me rappelle d'une conversation antérieure.

par **zeus** » 13 juin 2006, 14:14

Je trouve ça extremement bizarre vu qu'on touche à la nomr SQL/ANSI quand même

Quelle est la requete que tu as essayé ?

par **Vorkosigan** » 13 juin 2006, 14:13

sous Oracle 10g, si les champs du GROUP By ne sont pas pas tous dans le SELECT, il y a une erreur retournée

Pas sur le serveur ou je bosse

Peut-etre est-il configuré d'une maniere particuliere ?

Dynamic SQL Error SQL error code = -104 invalid column refer

Répondre

Étendre la vue Revue du sujet : Dynamic SQL Error SQL error code = -104 invalid column refer