bon j'ai déposé ma base sur ci-joint, voici le lien http://www.cijoint.fr/cjlink.php?file=cj201002/cijp1cuAPw.odb
Le 9 février 2010 19:20, Marie-Pierre CORONEL <mariepierre....@gmail.com> 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, 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: users-unsubscr...@fr.openoffice.org >> For additional commands, e-mail: users-h...@fr.openoffice.org >> >> >
