I did a bit of testing on this as I use MDX a lot and wanted to understand the behaviour, all in PAW 2.0.55 so a little old.
The good news is that if I try and create a set in a TI with the nonsense MDX the TI aborts, so as you would expect some kind of error happens.
Directly in a set I could reproduce the issue, it appears to default to the first member when the member MDX is wrong.
I tested against a period dimension, as that is what I handy.
Code: Select all
{FILTER(TM1FILTERBYLEVEL(TM1SUBSETALL([Period]) , 0) ,
([}ElementAttributes_Period].([}ElementAttributes_Period].[Month Number]) >= 1)
AND ([}ElementAttributes_Period].([}ElementAttributes_Period].[Month Number]) <= 5))}
This returns a range of periods, I also added another numeric attribute "Test" where the periods were flagged differently, so I could tell the difference.
When I changed the MDX in the set to read the following (which causes a fatal error in a TI)
Code: Select all
{FILTER(TM1FILTERBYLEVEL(TM1SUBSETALL([Period]) , 0) ,
([}ElementAttributes_Period].([}ElementAttributes_Period].[a]) >= 1)
AND ([}ElementAttributes_Period].([}ElementAttributes_Period].[a]) <= 5))}
Then this returns the Month Number values, which happens to be first in the attributes dimension.
It's not just defaulting back to the last good MDX as if I first query Month Number, then Test and then "a" I get the Month Number results.
HTH, its certainly significantly less scary than it appeared since bad MDX fails on usage in a TI process. Personally all the MDX subsets in a system get created via a TI anyway so that I can reset / recreate and promote them as required. There's now the additional benefit that the MDX gets tested properly too...
