Monday, March 26, 2012

multi-select MDX issue from a client tool

Hi

This is the sample query which was getting generated by the client tool :
with member [Destination].[Destination].[Sum] as 'Aggregate({[Destination].[Destination].&[12],[Destination].[Destination].&[3]})'
select [Measures].[Value] on columns,
nonempty([Time].[Calendar].allmembers) on rows
from [Consolidation Prototype]
where ([Destination].[Destination].[Sum]

The above query was failing in SSAS. It was failing because of the implicit use of current member somwhere.

The error was

The MDX function CURRENTMEMBER failed because the coordinate for the attribute contains a set.

Mosha has written a few blogs over the network explaining the reason for the problem. My guess is that, although, I am not using the currentmember across Destination dimension explicitly in the above query, it is getting used in the MDX script while evaluating the values of the measure [Measures].[Value] .


So while evaluating the currentmember for Destination dimension, its finding 2 current values and fails, because SSAS cannot handle this scenario.

Now the interesting part :


If I replace the slicer clause with this one ({[Destination].[Destination].[Sum]}) i.e just enclosing the calculated member with {}, it works fine.

There is one more solution as well :
If I replace the aggregate statement with the following:

Aggregate({[Destination].[Destination].&[12],[Destination].[Destination].&[3]},[Time].[Calendar].currentmember)

Would anyone be able to explain to me the reason for this kind of behaviour?

ZA

"If I replace the slicer clause with this one ({[Destination].[Destination].[Sum]}) i.e just enclosing the calculated member with {}, it works fine.

There is one more solution as well :
If I replace the aggregate statement with the following:

Aggregate({[Destination].[Destination].&[12],[Destination].[Destination].&[3]},[Time].[Calendar].currentmember) "

Just a guess, but the above tweaks may be enough to stop the replacement that Mosha describes in his blog :

Writing multiselect friendly MDX calculations

...

AS's query engine recognizes the shape of the queries where there is query calculated member doing Aggregate over constant single grain set, and this calculated member (or members if there are multiple multiselects in different hierarchies) is in the WHERE clause. And when AS detects this situation, it replaces the calculated member in the WHERE clause with the corresponding set.

|||I thought so. Thanks anyways, Deepak.

No comments:

Post a Comment