Marie-Pierre CORONEL a écrit :
A Docgranville :
Je ne suis sûre absolument de rien, je débute en SQL. J'en suis à quoi
? mon 3ème jour peut-être ? Et en discontinu en plus... Cette commande
(Every, sa traduction française c'est tous) je l'ai trouvée dans mon
bouquin et elle a été reconnue par base, j'ai enfin cessé d'avoir une
erreur... sauf qu'aucun résultat. J'ai cherché une fonction qui me
semblait adéquate et qui m'évite l'affichage du message erreur envoyé
par le logiciel qui réclamait une "function" et/ou je ne sais plus
"group by" et dont j'espèrais évidemment le bon résultat...
Le message d'erreur que tu recevais, il était relatif à ta clause Group
By ? C'est un grand classique en présence des fonctions d'agrégation
(les fonctions de type COUNT ou SUM par exemple) ; j'ai longtemps galéré
avec elles, jusqu'à ce que je retienne la chose suivante : en présence
d'une telle fonction dans une requête, il faut ajouter une clause "Group
By" et mettre derrière le "Group By", tous les champs figurant derrière
le SELECT mais qui ne sont pas affectés d'une fonction d'agrégation ; en
français je dirais que dans une requête du type "SELECT Ville, Année,
SUM(Naiss) as Naissance, SUM(Mort) as Décès FROM EtatCivil" il faudra
mettre un "Group By" dans lequel il faudra faire figurer Ville et Année
; ce n'est pas exact à 100% (il y a des cas dans lesquels la requête
marche alors qu'un champ n'est pas derrière le Group By et qu'il n'est
pas affecté d'une clause d'agrégation et que ça ne devrait donc
théoriquement pas marcher) mais si tu respectes ça, tu es certaine de ne
pas avoir de message d'erreur sur le problème du Group By.
Je ne cherche nullement à regarder l'effet de ma jolie requête, je
passe d'un mode à l'autre pour essayer de comprendre pourquoi et
comment. Et parce que ça m'a plutôt réussi d'ailleurs il y a quelques
jours, pour une autre formule compter, beaucoup plus simple, sans
doute parce qu'elle ne concerne qu'une table, et que je n'arrivais pas
à créer par l'outil graphique. Il m'a suffit de générer la sélection
des champs par l'outil graphique et de taper COUNT sur la formule SQL
puisqu'il me refusait la fonction nombre dans l'outil graphique. En
fait j'attendais de l'outil graphique qu'il m'aide à comprendre
comment sont composées les phrases SQL et réciproquement, comment les
phrases SQL sont représentées dans l'outil graphique...
Les alias c'est l'assistant qui les propose systématiquement.
J'ai pu constater en effet que passer sur l'outil graphique modifie
même la formule entrée en SQL, et ce dans un contexte où j'ai constaté
une dégradation d'affichage d'une de mes bases en 3.2... Je manquais
de repères, j'ai bien peur de ne plus en avoir du tout...
Je pense que si les aller/retour peuvent parfois être utiles pour cela
au début (au tout début), les limites de l'outil graphique apparaissent
vite et, même s'il peut paraître un peu difficile à maîtriser, le
langage SQL est beaucoup plus puissant que ne l'est l'outil graphique ;
je dirais que une fois que tu as compris (à l'aide de l'outil graphique)
la structure de la requête SELECT... FROM... WHERE... ORDER BY..., il
faut oublier l'outil graphique et tenter toi-même de rédiger tes
requêtes en partant de quelque chose qui marche, puis en y ajoutant des
complications "une par une", pour voir où ça coince (et ne pas chercher
à un endroit si l'erreur vient d'ailleurs) et avec sous la main un bon
manuel de référence (pour vérifier que la forme a bien été respectée).
Bon, je vous remercie de vos réponses, mais je les regarderai à tête reposée...
Sur la question de l'hébergeur, ben... je vais voir comment ça marche...
Bonne soirée.
A+
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
