[Designer V5-V6] Problème d'invite identique [Résolu]

[dvdavid]

Bonjour,

J'ai créé dans mon univers un indicateur qui est filtré sur une période à partir d'une invite de type @Variable.

Sous Bo, lorsque je créé un premier fournisseur de données avec cet indicateur et que je l'exécute, il me demande bien les dates de début et fin, je saisi alors 01/01/2010 au 31/03/2010.

Lorsque je créé un 2ème fournisseur de données, il me demande bien également les dates de début et fin, je saisi alors 01/01/2011 au 31/03/2011.

J'obtients alors deux chiffres différents, un sur 2010 et l'autre sur 2011.

Par contre, lorsque je rafraichit, l'état, il agrège les invites (puisque même libellé), je ne peux donc saisir que 2010 ou 2011, et ne donc obtenir les chiffres rafraichis pour chacune de ces périodes.

Y-a-t-il une solution? une manière plus adaptée?
Merci d'avance

[bastoonet]

Il faut que tes invites aient des libellés différents, il n'y a pas d'autre solution

- tu peux modifier cela dans le SQL de ta requete
- tu peux utiliser un objet personnel
- tu peux créer 2 objets distincts dans ton univers (bof)
- tu peux supprimer l'invite en condition de ton indicateur et les créer dans tes requetes

[TomDuBouchon]

Bonjour,

Un espace à la fin du libellé peut être fort utile dans ce cas... Mais personnellement je préfère savoir les invites de quelle requête je rafraichis.

[dvdavid]

Sauf qu'il s'agit du même indicateur dans 2 fournisseurs différents, je ne peux donc pas mettre un espace, cela revient exactement au même.

J'ai mis le filtre de période "@variable" dans l'univers car en fait il faut non seulement que je prenne les données entre une date D1 et D2, mais aussi que j'exclus les données dont la date d'annulation est inférieure ou égale à D2.

Code :

DAT_DON BETWEEN @variable ('Date début') AND @variable ('Date fin') AND (DAT_ANNUL IS NULL OR DAT_ANNUL > @variable ('Date fin'))

J'ai donc pensé que c'était plus simple de mettre ce filtre directement dans l'indicateur plutôt que l'utilisateur ai à le créer à chaque fois, sachant qu'il pense rarement à prendre en compte DAT_ANNUL!

[Julien59]

Il va falloir trouver un moyen pourtant
Tant que les invites auront le même libellés, elles s'agrégeront.

Je suppose que je suis utilisateur et que je dois rafraichir ton état :
Je lance le rafraichissement, les invites apparaissent :

Code :

1
2
3
4
Date de début :
Date de début :
Date de fin :
Date de fin :

Laquelle correspond à quoi ?
Dans tous les cas, je pense qu'il est nécessaire de distinguer les 2 invites.

[bastoonet]

Je campe sur mes positions, si tu sais que tu dois rencontrer ce problème, il ne faut pas mettre d'invite dans la clause where de ton objet dans designer.
Tu devras donc pour chaque rapport créer toi même tes 2 invites.

Autres solution à étudier, tu peux peux-être créer 2 conditions prédéfinies dans le designer et les utiliser dans tes 2 requetes....


Mais si tu veux garder ton objet pour simplifier le boulot aux utilisateurs, alors quand tu utilises 2 requetes avec cet objet dans un meme rapport (donc utilisateurs un peu avancé) alors tu peux utiliser un objet personnel ou modifier les libellé des invites dans le SQL....

On ne peut pas tout avoir

[dvdavid]

bien tant pis
merci à tous.