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]
