2009-04-14 9 views
0

J'utilise la fonction CurrentMember dans l'expression CellData d'un rôle pour restreindre l'accès à un cube via une dimension spécifique. Cela fonctionne comme prévu avec une exception. Même si l'option slicer est utilisée pour filtrer les données que le rôle n'a pas le droit de voir, la chaîne '# N/A' est affichée dans toutes les cellules.CurrentMember (MDX) Ignore Slicer Dimension

Après avoir inclus la dimension à laquelle le rôle a restreint l'accès dans un axe, les valeurs de la cellule sont affichées comme prévu.

Il me semble que la fonction CurrentMember ignore la dimension de la trancheuse. Est-ce le cas? Comment dois-je aborder ce problème?

+0

Je posté cette question dans le MSDN Managed Newsgroups et a obtenu une réponse d'un représentant Microsoft ... http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft .public.sqlserver.olap & tid = b4fcb648-3d05-4310-9676-f40c2f7b839c & cat = & lang = & cr = & sloc = & p = 1 –

+0

Je ne suis pas sûr de ce qui est arrivé à poster sur les forums msdn mais le lien dans mon commentaire ci-dessus ne fonctionne plus . SQL Monster semble l'avoir mis en cache ici ... http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-olap/13948/CurrentMember-Function-Ignores-Slicer-Dimension –

Répondre

0

Mon conseil, sérieusement, est de fuir les cubes qui vous obligent à restreindre l'accès en utilisant des valeurs de cube. Été là, fait cela, gaspillé trop de temps et toujours fini avec une solution instable. DEFINITIVEMENT, n'utilisez PAS de 'rôles' dans OLAP.

+0

J'ai fini par prendre vos conseils et les rôles supprimés de ma solution. –

1

Cela dépend de la façon dont vous faites votre requête avec les filtres. Si vous générez une sous-requête (en utilisant la zone de filtre supérieure dans SSMS ou BIDS), currentMember retournera le membre All - c'est ainsi que les sous-requêtes ont été conçues pour fonctionner. Si vous utilisez la requête inférieure dans SSMS ou BIDS, elle utilisera la clause WHERE et vous devriez voir les résultats attendus.

Et vous pouvez être mieux d'utiliser l'onglet de données de dimension au lieu des données de cellule si vous filtrez juste par des membres de dimension.

+0

Je ne suis pas sûr de bien comprendre votre solution, mais je pense que cela signifierait que ma «sécurité» n'entrerait en vigueur que si j'incluais la dimension dans la requête. –

+1

Non, les rôles de sécurité sont toujours actifs, bien que la relecture de votre message d'origine, en utilisant .CurrentMember est un peu inhabituel et pourrait causer des problèmes. Je n'irais pas jusqu'à dire de ne pas utiliser les rôles, mais j'essaie d'éviter d'utiliser la sécurité basée sur les cellules. Si vous lisez la documentation, il est conçu pour afficher # N/A si la valeur est restreinte. Si vous souhaitez que les utilisateurs ne voient pas un certain ensemble de membres, vous devez sécuriser l'utilisation de l'onglet DimensionData et non de CellData. –

Questions connexes