Discussion :

[calagan99]

Bonjour à tous,

je me démène depuis un long moment avec SSAS et SSRS sur un sujet que je ne parviens pas à résoudre : le passage de paramètres de rapport à une requête MDX.

Voila ce que je souhaite faire :
- un premier dataset basé sur une requête SQL basique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"SELECT ID, LIBELLE FROM MATABLE WHERE ID_PARENT = @ID_PARENT"

Le paramètre @ID_PARENT est renseigné par le user à l'exécution du rapport.

- un second DataSet basé sur une requête MDX. Celle-ci doit être filtrée en tenant compte des ID retournés par le premier Dataset.
Voila ce que j'ai fait pour le moment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 SELECT NON EMPTY { [Measures].[NUMBER Count] } ON COLUMNS, NON EMPTY { ([SOC].[SOC].[SOC].ALLMEMBERS ) } DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS FROM ( SELECT ( STRTOSET(@SOCS, CONSTRAINED) ) ON COLUMNS FROM [DW])

Le paramètre @SOCS est multivalué, il est basé sur les éléments retournés par le premier DataSet.

Quand j'exécute le rapport :
je renseigne @ID_PARENT dans la première invite.
Ma liste de @SOCS est alors bien renseignée.
Je sélectionne un ou plusieurs éléments dans la liste proposée puis exécute le rapport.
J'ai alors une erreur me disant que la syntaxe est incorrecte dans le second dataset. la value du paramètre SOCS n'est apparemment pas correcte.

Je ne vois pas comment procéder pour réussir ce passage de paramètre.
Auriez-vous une idée pour m'aiguiller s'il vous plaît ?

D'avance merci.

Bonne journée et bon week-end

[FrancoisJehl]

Le truc c'est que ta liste va te renvoyer un truc comme ça "1,2,3,4,5" vu que tu le récupères côté SQL. Et que ça on peut le tourner dans tous les sens ce n'est pas une expression de set MDX. (Au contraire d'un truc comme {[Soc].[Soc].&[1], [Soc].[Soc].&[2]...})
Donc une des solutions possibles qui ne modifie rien de ce que tu fais - il est aussi possible de remplir ton premier paramètre en MDX pour avoir directement les MEMBER_UNIQUE_NAME, voire d'appliquer le Join plus tôt - pourrait être d'utiliser une fonction de chaîne Join() pour remettre la définition de tes membres si ça vient du SQL. Bon attention c'est tapé de tête hein c'est probablement pas fonctionnel tel quel.

Un truc du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
STRTOSET
(
'{"+"[Soc].[Soc].&["
   +Join(Parameters!Socs.Value,"],[Soc].[Soc].&[")
   +"]"+"}'
, CONSTRAINED
)

[calagan99]

Merci François,

à vrai dire, je m'attendais un peu à cette réponse

j'ai également essayé de faire en sorte que la requête SQL de mon premier dataset formate le membre qui m'intéresse de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT  '[SOC].[SOC].&[{'+ convert(varchar(36),id_soc) + '}]' as id_soc, lib_soc from socs where id_parent = @id_parent

J'exploite alors id_soc en tant que value utilisée par le paramètre @SOCS de la requête MDX.

Si je procède comme cela, je n'ai aucun résultat.

[FrancoisJehl]

Et en virant le constrained?

[calagan99]

En supprimant le CONSTRAINED c'est beaucoup mieux en effet

Etant donné que le report ne sera exposé qu'en interne, est-ce grave/dangereux/léger de ne pas utiliser CONSTRAINED ?

D'autre part, je suis maintenant confronté à une chose que je ne comprends pas :
Lorsque je définis mon paramètre @SOCS, si je ne lui affecte aucune valeur par défaut ou si ma valeur par défaut ne contient aucun élément, le dataset ne contient aucun champ et provoque une erreur à a génération du report.
Une fois que le dataset a été vidé de ces champs, plus moyen (même en affectant une default value non vide) de récupérer les champs du dataset, je suis obligé de le supprimer puis de le recréer.
Etrange, non ?

[FrancoisJehl]

Pour le CONSTRAINED, essaie de mettre [Soc].[Soc].[Soc].&[xxx] (Dimension-Hiérarchie-Niveau, si Soc est bien le nom des trois) ça l'aidera sûrement. Quant à CONSTRAINED c'est juste pour éviter que quelqu'un te tape le MDX directement et puisse voir ce qu'il souhaite, donc oui ça peut être mieux de le faire tourner avec. CONSTRAINED ne marche que si l'expression est une enfilade de membres qualifiés (i.e. comme ci dessus) séparés par des brackets.

Quant à ta seconde réponse... étrange effectivement. Pour te protéger de cela vérifie que @SOCS contient bien {} seulement pour symboliser le vide: normalement un StrToSet de {} doit renvoyer quelque chose de valide, vide mais valide.

[calagan99]

Merci beaucoup pour ton aide François
La documentation sur le sujet n'est pas extrêmement fournie et j'y vais par conséquent un peu à tâtons...

J'ai modifié le retour de mon premier DataSet sur le modèle de ce que tu me proposes.
Mon paramètre @SOCS reçois désormais [Soc].[Soc].[Soc].&[xxx].
Cela a changé la donne dans la mesure où la valeur par défaut affectée à @SOCS n'est plus prise en compte lors de l'exécution du report.
Par contre, aucun changement pour ce qui est du CONSTRAINED ou de la perte des champs du dataset en cas de paramètre par défaut vide.

[FrancoisJehl]

Et tu as bien des '{}' concaténés au début et en fin de ta chaîne SOCS?

[calagan99]

François,

non, pas de {} dans mon paramètre.
Celui-ci étant défini comme dépendant d'un premier Dataset, je n'ai pas la main sur la forme du param passé au MDX.

Est-ce que je peux agir sur ce point directement dans la définition XML du report ?

[FrancoisJehl]

Tu peux ajouter des { } avant et après ton paramètre dans la requête cible.

[calagan99]

François : avec du retard, merci beaucoup pour ton aide. Mon problème est résolu. Ta solution était la bonne.