Puis-je me risquer à cette question :
Avec cette requête voir copie d'écran :
 
J'obtiens bien ce que je veux: le total des prix par
Genre. Cependant j'ai obtenu cette requête en la modifiant et en
mettant la fonction GROUPE dans la colonne genre, l'assistant ne m'a
jamais proposé de groupement; mais peut-être n'ai-je pas tout compris... auquel cas je suis preneur d'explications
Merci
Claude
Le 10/06/2010 08:57, Claude FRICARD a écrit :
Doc,
Je préfère de beaucoup l'explication à .....et si cette explication m'a
déjà été donnée, j'en ai pas souvenance mais je m'en excuse auprès des
auteurs.
Peut-être dire ma démarche: pour ce cours à l'association j'entends
montrer comment construire une base simple : une gestion de
bibliothèque. J'ai fait un tutoriel décrivant cette création de bout en
bout, m'appuyant donc sur la même base que le session précédente.
Pour ce qui est de ce calcul de prix dans un 1er temps j'ai indiqué
comment faire la somme des prix sans tenir compte du GENRE (roman,
fiction,etc.) puis en introduisant un critère "en dur" comme ROMAN pour
faire la somme des prix des livres du GENRE : Roman, et enfin montrer
que ce paramètre GENRE peut-être fourni à l'invocation de la Requête
grâce à la boite de dialogue générée par le LIKE :Recherche.
Ce que j'obtiens (en décochant la case visible ... ;-) ) .
De fait comme dit Bernard (Ribotb) c'est plus cohérent de faire un
GROUP BY GENRE.
Merci à vous
A+
Claude
Le 09/06/2010 19:50, Docgranville a écrit :
Le 09/06/2010 19:21, Claude FRICARD a écrit :
Doc,
Je perçois dans ta réponse un peu de sarcasme...Il reste que agrégat ou
pas je ne comprends pas pourquoi une case de visibilité ferait la
différence. ... ;-)
Il est vrai que le code SQL n'est pas tout à fait le même suivant la
visibilité ou pas :
* SELECT SUM( "Prix" ) AS "Total GENRE", "GENRE" FROM "OUVRAGES"
AS "OUVRAGES" WHERE "GENRE" LIKE :Recherche
* SELECT SUM( "Prix" ) AS "Total GENRE" FROM "OUVRAGES" AS
"OUVRAGES" WHERE "GENRE" LIKE :Recherche
Pour que je ne revienne pas l'année prochaine avec ma question....
peut-être m'expliquer le pourquoi des choses, quitte à me dire que si
ça fonctionne avec Access c'est une anomalie...
Salutations mon cher Doc
Claude
Claude,
Il y avait effectivement du sarcasme (léger) dans mon propos ; la
raison en est que "le pourquoi des choses" comme tu dis t'a déjà été
expliqué l'année dernière mais que tu n'as pas voulu l'entendre.
Depuis l'année dernière, tu fais une fixette sur cette fameuse case de
visibilité alors que ce n'est pas le noeud du problème.
Je t'avais écrit l'année dernière : "ce qui me semble important (mais
là, c'est moi qui extrapole puisque je ne sais pas exactement ce que tu
comptais faire), ce n'est pas de constater qu'il suffisait de décocher
la case visibilité pour que la requête fonctionne, mais plutôt le fait
de savoir qu'il fallait mettre une clause de groupement dans la
deuxième colonne, pour parvenir à faire fonctionner la requête telle
qu'elle se présentait"
En fait, en décochant la case de visibilité, ta requêtes ne porte plus
sur le champ "GENRE" et il n'y a plus qu'une seul champ qui est
présenté, avec une condition d'agrégation (le SUM).
De ce fait, tu supprimes la cause de l'erreur, qui était que ta requête
portait sur plusieurs champs, dont certains étaient dans des calculs
d'agrégation et d'autres étaient hors des calculs d'agrégation (ces
derniers devant alors obligatoirement être cités derrière la clause
Group by) ; donc, pour toi cocher ou décocher cette fameuse case rend
valable ou non ta requête ; sauf que, précisément, dans les deux
versions de la requête que tu exposes ci-dessus, la grande différence,
c'est que la première (qui ne fonctionne pas) porte sur deux champs (et
elle ne fonctionne pas à cause du second), alors que la seconde ne
porte plus que sur un champ, la clause de visibilité ayant eu pour
effet collatéral de supprimer ton second champ.
Après, la raison pour laquelle Access (que je ne connais pas)
fonctionne différemment, je ne sais pas.
A+
|
