Odd OLAP cube set behavior question

Derosier, Cindy 21 Reputation points
2021-10-20T18:23:01.49+00:00

I am currently working with a client that has several OLAP cubes that contain date sets. When some users are accessing the cubes and pulling in the sets the numbers are not correct. So for example a user is pulling in 13 wk set and sales calculation the numbers are not correct. When they change to 26 week set the numbers are correct. I have tried to recreate the issue and cannot reproduce it in Excel, on the server. I have run profiler to examine the MDX and the queries are identical between mine and the user. The permissions are the same we both have full access to the data. Different users have issues with different sets. One user is 8 wk and 13 wk and another user is 52 wk and current year. The set are all created identically with the exception of the number of weeks.

Also if the same user pulls in an additional dimension such as sku the row level data when selected will total to the correct number but the subtotal line or grand total line is still not correct.

Does anyone have any idea what could be causing this odd and random behavior?

SQL Server Analysis Services
SQL Server Analysis Services
A Microsoft online analytical data engine used in decision support and business analytics, providing the analytical data for business reports and client applications such as Power BI, Excel, Reporting Services reports, and other data visualization tools.
1,245 questions
{count} votes

Accepted answer
  1. Darren Gosbell 2,371 Reputation points
    2021-10-24T21:43:29.687+00:00

    So that version number is SSAS 2014 RTM. There was a rare issue in roughly that timeframe with certain combinations of features where you could get an incorrect cache hit. I only ever saw this once and it was on one of the SSAS 2012 updates, but it was in that 2014 timeframe. In our scenario when two similar queries were run one after the other the subtotals from the first query were incorrectly returned in the second query. If you ran the queries in the other order you got the reverse behaviour. We also found that running an XMLA clearcache command before running the second query temporarily "fixed" this issue. So that is one test you can do. If running a clear cache, then re-running the query fixes the issue then you are hitting this bug and you should update to the latest CU

    0 comments No comments

0 additional answers

Sort by: Most helpful