- parmi les questions que je me suis posées tout l'après-midi, c'est : y a-t-il un ordre de déclaration des tables derrière FROM ou suffit-elle qu'elles soient listées ? (l'ordre serait fonction des champs du SELECT donc)
- dans les bouquins que j'ai trouvés sur GROUP BY, ils disent qu'on doit mettre toutes les variables contenues dans le SELECT et pas les seules variables non affectées par une fonction mais j'essayerai ta solution. - sur les variables accentuées j'en ai qui fonctionnent dans une autre base, mais comme dans cette base je n'ai pas encore créé les rapports (je suis infoutue pour le moment de trouver où on les déclare dans les rapports), je peux encore les changer... C'est ennuyeux quand même je trouve... - la solution pas à pas que tu as proposé, c'est celle que j'ai suivi (ma requête d'il y a quelques jours qui fonctionne)... mais l'élément perturbateur pour moi, c'est que là j'avais à travailler sur 2 tables (en plus des soucis que j'ai rencontrés dans la journée sur des choses qui fonctionnaient et ne fonctionnent plus correctement) et de guerre lasse, j'ai fini par céder sur la fonction et le group by (le message erreur parlait de fonction et de group by, avant même que j'insère count puisque j'ai compris qu'il fallait l'insérer en SQL directement, lui, la dernière fois), j'ai aussi fini par céder en désinstallant 3.2 et repassant à 3.1.1 d'ailleurs un peu avant de quitter le travail... et j'avais raté une question tout à l'heure. Le mois considéré est en toutes lettres, parce que je les ai entrés directement en zone de liste (arf, va falloir que je regarde si j'ai mis un accent à août :s). Le 9 février 2010 18:53, Docgranville <[email protected]> a écrit : > 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] > >
