non je n'ai pas regardé ta petite base, je me la suis réservée pour demain matin :) je reconnais que j'étais très excédée ce soir d'avoir planché tout l'après-midi pour rien grrr
Je te tiens au courant :) et merci encore :) Le 9 février 2010 19:35, ribotb <[email protected]> a écrit : > As-tu regardé ma petite base et la requête qui y est contenue ? C'est juste > pour savoir si j'ai bien compris ce que tu voulais. > 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 <[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] >>> >>> >>> >>> >> >> >> > > > --- > 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: [email protected] > For additional commands, e-mail: [email protected] > >
