ribotb
Tue, 09 Feb 2010 10:37:11 -0800
Merci. Bernard Marie-Pierre CORONEL a écrit :
- 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 <docgranvi...@aol.com> 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, jepasse 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êtereposée... Sur la question de l'hébergeur, ben... je vais voir comment ça marche... Bonne soirée.A+ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
--- Antivirus avast! : message Sortant sain. Base de donnees virale (VPS) : 100208-1, 08/02/2010 Analyse le : 09/02/2010 19:35:26 avast! - copyright (c) 1988-2010 ALWIL Software. http://www.avast.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org