J'ai décidé d'écrire mon commentaire sur votre réponse, M.Ali, en réponse à ma propre question, car j'ai trouvé un moyen de résoudre ce problème. Peut-être n'ai-je pas suffisamment expliqué mon problème. Je sais comment fonctionne la chose ci-dessus et comment transmettre des paramètres basés sur un ensemble de données, à travers le SQL pour créer un autre ensemble de données, plusieurs valeurs autorisées ou non. J'apprécie votre réponse cependant !
Le problème que j'ai est que la requête qui définirait ma liste de valeurs pour le paramètre et la requête pour l'ensemble de données réel sont les mêmes. Et c'est une énorme requête. En d'autres termes, là où il est écrit "TABLE" dans l'exemple de code, j'ai plusieurs centaines de lignes de code. Et mon objectif était de ne pas avoir toute cette requête définissant les deux ensembles de données. Si je devais à l'avenir modifier la requête, je devrais le faire à plusieurs endroits. Voici comment je l'ai résolu :
J'ai placé la requête principale dans un jeu de données partagé au lieu de l'intégrer dans mon rapport. Et j'ai ensuite ajouté une fonction row_number à ma requête comme suit :
SELECT ID, Value, UserID, rn = ROW_NUMBER() OVER(PARTITION BY UserID ORDER BY UserID)
FROM *my huge query*
Cela signifie qu'il n'y a qu'une seule ligne 'rn =1' par UserID. Puis je suis retourné à mon rapport. Mon DataSet1 d'origine pointerait alors simplement vers l'ensemble de données partagé. Le DataSet2 (le paramètre un) pointerait également vers l'ensemble de données partagé avec la seule différence que j'ai ajouté un filtre à cet ensemble de données disant 'rn =1'. J'ai ensuite créé un paramètre avec "autoriser plusieurs valeurs" qui a pris ses valeurs de DataSet2. Et cela fonctionne comme un charme. De cette façon, je peux simplement accéder à l'ensemble de données partagé lorsque j'ai besoin de mettre à jour la requête, et DataSet1 et DataSet2 seront mis à jour en conséquence !
Succès :)
Encore une fois, merci pour votre réponse !
