Solve order

Hi !!

I'm migrating my AS2000 to AS2005 but I have a problem. In my AS2000 I have a lot of calculated members and some MDX queries that use those member.

The problem is: In AS2005 the order of calculations changed. Now the calculations are done before the aggregations in the MDX querie. But I have more than 300 calculated members and change one by one seems to be very hard. How can I change my MDX querie to do the aggregation before the calculation of my calculated members

Waiting for help.

Thanks

http://msdn2.microsoft.com/en-us/library/ms143742.aspx

Custom level formulas aggregate differently

If a cube contains a dimension with custom level formulas, and also contains dimensions both before and after it with custom member formulas and/or unary operators, then the cube may return different results than previous versions of Analysis Services. This occurs because calculation precedence rules have changed.



Answer this question

Solve order

  • Netliner

    Thanks for the posts...

    But I solved my problem using the AGGREGATE function. Using this function I could aggregate first then do the calculation of my cube.


  • nagual

    We have been told that this issue is fixed in the SP1 of SSAS 2005. There is a property that needs to be set.

    <CalculationPassMode>1</CalculationPassMode>

    With the SP1 of SSAS 2005 the user must set this property to 1 and then the solve order will apply to both the Cube, Session, and Query calculations.

    HTH,

    - Steve



  • Mazmo

    Hi Rodrigo,

    Custom level formulas aren't the same as calculated members - if you only have calculated members then you should be ok with your migration, because as with AS2K the calculation is done after aggregation has taken place.

    However, solve order has changed in other ways, most notably in that it's now not possible to create query or session-scoped calculated members which have solve orders less than calculated members defined on the server. There are some exceptions which aren't documented anywhere, the only one that I know about being if the query or session-scoped calculated member consists of a single AGGREGATE function.

    Regards,

    Chris



  • Hardik Zaveri

    Steve - I wouldn't advise to rely on this property heavily - it has some undesirable side effects (disabling all the caching, for example, and more). There is a better solution to your problem - unfortunatelly it is not part of SP1. Please contact PSS or me directly to discuss the best way to solve this problem. moshap@microsoft.com
    Mosha


  • Solve order