Interesting... thanks, Reed. Here's an excerpt of the email I got from the dev team when I reported this problem (where Measures.Test was my old-style calc):

 

 

Hi Chris,

 

This has turned out to be much more interesting than I had thought.

After replicating your original scenario, I was trying to figure out why the behavior different between Monday and Tuesday. That's when I thought I found that sequencing gave the same result.

 

You are definitely correct that the "new style" behaves differently than the "old style". And I missed the difference when I looked at it before. I would argue, however, that it's not really a bug--although if MS wants to call it a bug, that's their business; there are plenty of things I think are bugs that they don't acknowledge :-).

 

The whole issue appears to be simply that the "new style" script command increments the Calculation Pass, while the "old style" calculation member command does not. So whenever you create a new style calc member right after a script command, the pass gets incremented and the calc member wins. If you create old style calc members right after a script command, they're still on the same pass, so solve order comes into play. The reason they call it a bug is probably because they're trying to make solve order completely irrelevant. If you just add ,SOLVE_ORDER = 1 to an "old style" calculated member, it suddenly wins, and thus acts just like a "new style" one.

 

Here's the series of commands that clarified it for me:

 

CREATE [PassNumber]  = CalculationCurrentPass();

[Date].[Day Name].&[1]=100;
CREATE MEMBER CURRENTCUBE.[MEASURES].[Old1] AS 10,SOLVE_ORDER=1;
Create [New1] = 1;
[Date].[Day Name].&[2]=200;
CREATE MEMBER CURRENTCUBE.[MEASURES].[Old2] AS 20,SOLVE_ORDER=1;
CREATE [New2] = 2;
[Date].[Day Name].&[3]=300;
CREATE MEMBER CURRENTCUBE.[MEASURES].[Old3] AS 30,SOLVE_ORDER=1;
CREATE [New3] = 3;
[Date].[Day Name].&[4]=400;

 

Here's the MDX query that I used to minimize having to tweak the MDX whenever I changed the script. Stepping through the script as it executed was very revealing.

 

select Measures.AllMembers - Measures.Members on 0,
[Date].[Day Name].members on 1
from [adventure works]

Thanks again for the topic. It has been very interesting.

 

Cheers,

Reed

No, I promise you it is a bug! I have the dev team on record about it...

 

In your example you're showing the behaviour I would expect from the new style calculations. The point about my example is that out of the two assignments that take place before the declaration of [Old Style 2] only the first is applied - a clear inconsistency.

Hi Chris,

 

Interesting article, but I disagree with both your conclusions: a) that it's a bug, and b) that there's a difference between "old style" and "new style". I think the result you see is simply the new Solve Order behavior in a script: sequence determines precedence. Here's an analogous set of script commands (all using "new style") that displays a similar effect but making it clear that the sequence of the statements explains the results:

 

Create [New Style1] = 1;

[Date].[Day Name].&[1]=100;