7
votes

Passage de paramètre multivalue à une sous-rapport

J'ai un problème lorsque vous travaillez avec multivalue code> entre les rapports.

J'ai un rapport principal dans lequel j'ai défini un paramètre multivalue, que j'utilise pour exécuter une requête SQL à peupler son jeu de données. Le paramètre est utilisé dans la clause WHERE de la manière suivante: p> xxx pré>

Ça fonctionne bien et qui redevient les données attendues. P>

alors ce rapport principal passe ce paramètre à un sous-rapport. Le paramètre est également défini comme multivalue dans le sous-rapport et, autant que je sache dans la liste déroulante du paramètre, il reçoit les valeurs de la bonne manière. Quelque chose comme ça: a, b, c p>

La chose est que la requête qui remplit le jeu de données du sous-rapport ne renvoie rien. Il dispose également d'une clause où la clause est définie comme dans le rapport principal (qui fonctionne déjà) p> xxx pré>

si j'exécute la requête manuellement, à la codage des valeurs à quelque chose comme ceci: p> xxx pré>

Ça fonctionne, mais lorsque j'essaie d'utiliser le paramètre, il ne le fait pas. Donc, en quelque sorte, c'est perdre le format ou les valeurs de la manière. P>

J'ai essayé cette solution dans la définition de jeu de données du sous-rapport, qui a été proposée dans un autre thread: P>

 =join(Parameters!<your param name>.Value,",")


0 commentaires

3 Réponses :


13
votes

Cela devrait "travailler juste". Assurez-vous que le paramètre dans le sous-rapport est configuré en tant que multivalue, et j'utilise généralement exactement la même requête que dans le rapport parent pour fournir des valeurs disponibles.

Vérifiez que vous passez le paramètre entier à la sous-rapport: dans les propriétés de sous-rapport sur le rapport parent, la valeur du paramètre doit lire [@ myParamName] pas << Expr >> . Si elle se lit comme ce dernier, éditez l'expression et assurez-vous qu'il n'a pas de (0) à la fin. Mais = paramètres! myParamName.Value est correct, pas = paramètres! MyParamName.Value (0)


2 commentaires

Vous avez raison, cela devrait "travailler", mais ce n'est pas le cas. Donc, j'ai supprimé le rapport et j'ai créé à nouveau de zéro, cela a fonctionné. Apparemment, j'ai dû oublier quelque chose au milieu. Merci quand même pour votre réponse


Merci, cela m'a aidé à faire fonctionner le mien. IMPORTANT: "" paramètre dans la sous-rapport est configuré en tant que multivalue et utilisez exactement la même requête que dans le rapport parent pour fournir des valeurs disponibles. ". IMPORTANT: "Dans les propriétés de sous-rapport sur le rapport parent, la valeur du paramètre doit lire [@ myParamName] pas << EXPR >> " Ces conseils l'ont fait pour moi.



3
votes

vient de créer le rapport à nouveau à de nouveau le rapport et cela a fonctionné. J'ai dû oublier quelque chose au milieu.

Quoi qu'il en soit, juste au cas où quelqu'un en a besoin, les deux paramètres, celui dans le rapport principal et celui de la sous-rapport, doivent être définis comme multivalue. Ensuite, dans votre requête, vous devez utiliser dans dans votre classique, quelque chose comme ceci: xxx

et rien d'autre n'est avait besoin. Je n'avais pas besoin de faire ce qui suit: xxx

il vient de travailler pour moi


0 commentaires

3
votes

Je pense que je sais ce que vous avez fait, comme je l'ai été tiré ici en ayant le même problème. Les sous-rapports ont été configurés bien, mais en entrant dans la liaison des paramètres dans le rapport parent, la chute de la valeur n'a pas offert mon paramètre, j'ai donc utilisé le constructeur d'expression pour le sélectionner. Cela a quitté le gris << EXPR >> le marqueur de la valeur et ne fonctionnerais que lorsque je n'avais qu'une seule valeur sélectionnée dans la liste. Lorsque je l'ai remplacé avec [@ myParam] cela a fonctionné bien quel que soit le nombre de valeurs sélectionnées. Lorsque j'avais un coup d'œil sur le constructeur de valeur d'expression avait créé un peu plus près, il avait = paramètres! Myparam.value (0) . Supprimer le (0) la corrige également.


0 commentaires