Je pr=E9pare un =E9tat Access, qui doit prendre en compte des statistique=
s=20
selon deux unit=E9s, nous dirons Colis ou UVC.
Le premier champ contiendra la cha=EEne "Colis" ou "UVC", selon laquelle =
les autres champs, par des clauses IIf, fourniront les renseignements=20
ad=E9quats en cons=E9quence.
Pour que l'utilisateur puisse indiquer son choix facilement, la premi=E8r=
e=20
version de la requ=EAte de cet =E9tat indiquait comme premier champ=20
Iif(Forms("frmOuvertureEtat1").cadTypeRequete=3D1,"Colis","UVC")
Et =E7a marche bien, l'=E9tat sort effectivement les nombres de colis ou =
d'UVC selon la s=E9lection de l'utilisateur dans le formulaire.
L=E0 o=F9 =E7a se g=E2te, c'est que pour les totaux, l'utilisateur joue u=
n peu=20
les enfants g=E2t=E9s : il veut les totaux non pas en pied de groupe, o=F9=
on=20
aurait pu faire tout simplement des cumuls, mais en t=EAte de groupe, o=F9=
=20
il faut avoir recours =E0 des fonctions de regroupement comme DSum.
DSum, vous pouvez lui indiquer comme domaine une requ=EAte enregistr=E9e =
reqListing1, sur laquelle est bas=E9e l'=E9tat, mais si cette requ=EAte=20
enregistr=E9e est param=E9tr=E9e, l=E0 commence la gymnastique.
M=EAme si le param=E8tre, dans reqListing1, est dans un formulaire qui es=
t=20
bien ouvert donc avec la valeur lisible, certes l'=E9tat peut appeler des=
=20
conditions sur le champ param=E9tr=E9, mais si il se met =E0 appeler une =
fonction de regroupement sur cette requ=EAte, l=E0 on se retrouve avec un=
e=20
erreur, param=E8tre manquant.
On pourrait imaginer d'=E9crire une requ=EAte pour chaque valeur du=20
param=E8tre, mais alors on perd l'avantage de la fiabilit=E9 apport=E9e p=
ar le=20
code unique.
Comment s'en sortir proprement, autant que possible en conservant=20
l'avantage d'=E9viter la duplication de code ? Si en m=EAme temps on pouv=
ait=20
=E9viter l'usine =E0 gaz, bien s=FBr, =E7a serait encore mieux, mais peut=
-=EAtre=20
que l=E0 je demande beaucoup :)
J'avais bien pens=E9 =E0 aller chercher le domaine de la fonction de=20
regroupement dans les propri=E9t=E9s de l'=E9tat, mais je n'ai trouv=E9 q=
u'une=20
cha=EEne de caract=E8res RecordSource, qui fait appel =E0 la requ=EAte=20
param=E9tr=E9e ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
je ne sais si je comprends ce que tu cherches... mais, il me semble que tu as dans le pied de groupe une zone de texte indépendante qui comme source =Sum(un_champ)
mais, que tu souhaites en fait afficher cela dans l'en-tête du groupe?
si oui, pourquoi ne place tu pas directement cette zone de texte dans l'en-tête du groupe ?
Un Sum() ou Count() sur un regroupement peut-être placé dans le pied ou dans l'en-tête de ce groupe...
Je prépare un état Access, qui doit prendre en compte des statistiques selon deux unités, nous dirons Colis ou UVC.
Le premier champ contiendra la chaîne "Colis" ou "UVC", selon laquelle les autres champs, par des clauses IIf, fourniront les renseignements adéquats en conséquence.
Pour que l'utilisateur puisse indiquer son choix facilement, la première version de la requête de cet état indiquait comme premier champ Iif(Forms("frmOuvertureEtat1").cadTypeRequete=1,"Colis","UVC")
Et ça marche bien, l'état sort effectivement les nombres de colis ou d'UVC selon la sélection de l'utilisateur dans le formulaire.
Là où ça se gâte, c'est que pour les totaux, l'utilisateur joue un peu les enfants gâtés : il veut les totaux non pas en pied de groupe, où on aurait pu faire tout simplement des cumuls, mais en tête de groupe, où il faut avoir recours à des fonctions de regroupement comme DSum.
DSum, vous pouvez lui indiquer comme domaine une requête enregistrée reqListing1, sur laquelle est basée l'état, mais si cette requête enregistrée est paramétrée, là commence la gymnastique.
Même si le paramètre, dans reqListing1, est dans un formulaire qui est bien ouvert donc avec la valeur lisible, certes l'état peut appeler des conditions sur le champ paramétré, mais si il se met à appeler une fonction de regroupement sur cette requête, là on se retrouve avec une erreur, paramètre manquant.
On pourrait imaginer d'écrire une requête pour chaque valeur du paramètre, mais alors on perd l'avantage de la fiabilité apportée par le code unique.
Comment s'en sortir proprement, autant que possible en conservant l'avantage d'éviter la duplication de code ? Si en même temps on pouvait éviter l'usine à gaz, bien sûr, ça serait encore mieux, mais peut-être que là je demande beaucoup :)
J'avais bien pensé à aller chercher le domaine de la fonction de regroupement dans les propriétés de l'état, mais je n'ai trouvé qu'une chaîne de caractères RecordSource, qui fait appel à la requête paramétrée ...
Salut,
je ne sais si je comprends ce que tu cherches... mais, il me semble
que tu as dans le pied de groupe une zone de texte indépendante
qui comme source =Sum(un_champ)
mais, que tu souhaites en fait afficher cela dans l'en-tête du groupe?
si oui, pourquoi ne place tu pas directement cette zone de texte
dans l'en-tête du groupe ?
Un Sum() ou Count() sur un regroupement peut-être placé
dans le pied ou dans l'en-tête de ce groupe...
Je prépare un état Access, qui doit prendre en compte des statistiques
selon deux unités, nous dirons Colis ou UVC.
Le premier champ contiendra la chaîne "Colis" ou "UVC", selon laquelle
les autres champs, par des clauses IIf, fourniront les renseignements
adéquats en conséquence.
Pour que l'utilisateur puisse indiquer son choix facilement, la
première version de la requête de cet état indiquait comme premier
champ Iif(Forms("frmOuvertureEtat1").cadTypeRequete=1,"Colis","UVC")
Et ça marche bien, l'état sort effectivement les nombres de colis ou
d'UVC selon la sélection de l'utilisateur dans le formulaire.
Là où ça se gâte, c'est que pour les totaux, l'utilisateur joue un peu
les enfants gâtés : il veut les totaux non pas en pied de groupe, où
on aurait pu faire tout simplement des cumuls, mais en tête de
groupe, où il faut avoir recours à des fonctions de regroupement
comme DSum.
DSum, vous pouvez lui indiquer comme domaine une requête enregistrée
reqListing1, sur laquelle est basée l'état, mais si cette requête
enregistrée est paramétrée, là commence la gymnastique.
Même si le paramètre, dans reqListing1, est dans un formulaire qui est
bien ouvert donc avec la valeur lisible, certes l'état peut appeler
des conditions sur le champ paramétré, mais si il se met à appeler une
fonction de regroupement sur cette requête, là on se retrouve avec une
erreur, paramètre manquant.
On pourrait imaginer d'écrire une requête pour chaque valeur du
paramètre, mais alors on perd l'avantage de la fiabilité apportée par
le code unique.
Comment s'en sortir proprement, autant que possible en conservant
l'avantage d'éviter la duplication de code ? Si en même temps on
pouvait éviter l'usine à gaz, bien sûr, ça serait encore mieux, mais
peut-être que là je demande beaucoup :)
J'avais bien pensé à aller chercher le domaine de la fonction de
regroupement dans les propriétés de l'état, mais je n'ai trouvé qu'une
chaîne de caractères RecordSource, qui fait appel à la requête
paramétrée ...
je ne sais si je comprends ce que tu cherches... mais, il me semble que tu as dans le pied de groupe une zone de texte indépendante qui comme source =Sum(un_champ)
mais, que tu souhaites en fait afficher cela dans l'en-tête du groupe?
si oui, pourquoi ne place tu pas directement cette zone de texte dans l'en-tête du groupe ?
Un Sum() ou Count() sur un regroupement peut-être placé dans le pied ou dans l'en-tête de ce groupe...
Je prépare un état Access, qui doit prendre en compte des statistiques selon deux unités, nous dirons Colis ou UVC.
Le premier champ contiendra la chaîne "Colis" ou "UVC", selon laquelle les autres champs, par des clauses IIf, fourniront les renseignements adéquats en conséquence.
Pour que l'utilisateur puisse indiquer son choix facilement, la première version de la requête de cet état indiquait comme premier champ Iif(Forms("frmOuvertureEtat1").cadTypeRequete=1,"Colis","UVC")
Et ça marche bien, l'état sort effectivement les nombres de colis ou d'UVC selon la sélection de l'utilisateur dans le formulaire.
Là où ça se gâte, c'est que pour les totaux, l'utilisateur joue un peu les enfants gâtés : il veut les totaux non pas en pied de groupe, où on aurait pu faire tout simplement des cumuls, mais en tête de groupe, où il faut avoir recours à des fonctions de regroupement comme DSum.
DSum, vous pouvez lui indiquer comme domaine une requête enregistrée reqListing1, sur laquelle est basée l'état, mais si cette requête enregistrée est paramétrée, là commence la gymnastique.
Même si le paramètre, dans reqListing1, est dans un formulaire qui est bien ouvert donc avec la valeur lisible, certes l'état peut appeler des conditions sur le champ paramétré, mais si il se met à appeler une fonction de regroupement sur cette requête, là on se retrouve avec une erreur, paramètre manquant.
On pourrait imaginer d'écrire une requête pour chaque valeur du paramètre, mais alors on perd l'avantage de la fiabilité apportée par le code unique.
Comment s'en sortir proprement, autant que possible en conservant l'avantage d'éviter la duplication de code ? Si en même temps on pouvait éviter l'usine à gaz, bien sûr, ça serait encore mieux, mais peut-être que là je demande beaucoup :)
J'avais bien pensé à aller chercher le domaine de la fonction de regroupement dans les propriétés de l'état, mais je n'ai trouvé qu'une chaîne de caractères RecordSource, qui fait appel à la requête paramétrée ...
Gloops
3stone a écrit, le 09/04/2011 02:50 :
Salut,
je ne sais si je comprends ce que tu cherches... mais, il me semble que tu as dans le pied de groupe une zone de texte indépendante qui comme source =Sum(un_champ)
mais, que tu souhaites en fait afficher cela dans l'en-tête du groupe ?
si oui, pourquoi ne place tu pas directement cette zone de texte dans l'en-tête du groupe ?
Un Sum() ou Count() sur un regroupement peut-être placé dans le pied ou dans l'en-tête de ce groupe...
Ou alors je n'ai rien compris a ta question :-/
Oui, tout-à-fait. En fait, j'ai tardé à revenir, mais j'ai fini par avoir l'explication , beaucoup plus simple que les pistes que j'étais en train d'explorer : j e m'étais tout simplement trompé de champ de critère, je passais celu i destiné à l'utilisateur, donc en passant ça à SQL, ça ne donne rien d'autre qu'une erreur.
Une fois la bonne expression passée comme filtre, tout va bien. J'étais tellement persuadé que le problème était ailleurs, qu'il a fallu que je monte une requête de test, avec un état de test, que je me rapproche de la config initiale pas à pas, pour me rendre compte que ç a marche, et du coup j'ai corrigé l'état initial, et ça marche aussi.
Désolé, je m'étais bien dit qu'il fallait que je mette les choses a u point ici, et puis je suis rentré si tard ...
3stone a écrit, le 09/04/2011 02:50 :
Salut,
je ne sais si je comprends ce que tu cherches... mais, il me semble
que tu as dans le pied de groupe une zone de texte indépendante
qui comme source =Sum(un_champ)
mais, que tu souhaites en fait afficher cela dans l'en-tête du groupe ?
si oui, pourquoi ne place tu pas directement cette zone de texte
dans l'en-tête du groupe ?
Un Sum() ou Count() sur un regroupement peut-être placé
dans le pied ou dans l'en-tête de ce groupe...
Ou alors je n'ai rien compris a ta question :-/
Oui, tout-à-fait.
En fait, j'ai tardé à revenir, mais j'ai fini par avoir l'explication ,
beaucoup plus simple que les pistes que j'étais en train d'explorer : j e
m'étais tout simplement trompé de champ de critère, je passais celu i
destiné à l'utilisateur, donc en passant ça à SQL, ça ne donne rien
d'autre qu'une erreur.
Une fois la bonne expression passée comme filtre, tout va bien.
J'étais tellement persuadé que le problème était ailleurs, qu'il a fallu
que je monte une requête de test, avec un état de test, que je me
rapproche de la config initiale pas à pas, pour me rendre compte que ç a
marche, et du coup j'ai corrigé l'état initial, et ça marche aussi.
Désolé, je m'étais bien dit qu'il fallait que je mette les choses a u
point ici, et puis je suis rentré si tard ...
je ne sais si je comprends ce que tu cherches... mais, il me semble que tu as dans le pied de groupe une zone de texte indépendante qui comme source =Sum(un_champ)
mais, que tu souhaites en fait afficher cela dans l'en-tête du groupe ?
si oui, pourquoi ne place tu pas directement cette zone de texte dans l'en-tête du groupe ?
Un Sum() ou Count() sur un regroupement peut-être placé dans le pied ou dans l'en-tête de ce groupe...
Ou alors je n'ai rien compris a ta question :-/
Oui, tout-à-fait. En fait, j'ai tardé à revenir, mais j'ai fini par avoir l'explication , beaucoup plus simple que les pistes que j'étais en train d'explorer : j e m'étais tout simplement trompé de champ de critère, je passais celu i destiné à l'utilisateur, donc en passant ça à SQL, ça ne donne rien d'autre qu'une erreur.
Une fois la bonne expression passée comme filtre, tout va bien. J'étais tellement persuadé que le problème était ailleurs, qu'il a fallu que je monte une requête de test, avec un état de test, que je me rapproche de la config initiale pas à pas, pour me rendre compte que ç a marche, et du coup j'ai corrigé l'état initial, et ça marche aussi.
Désolé, je m'étais bien dit qu'il fallait que je mette les choses a u point ici, et puis je suis rentré si tard ...
