I have a strange problem in my cube when drilling down to details.
If I run the following query and leave out the DRILLTHROUGH, I get only one number as result, 7.
The Measure Counter is defined as "COUNT on lines" of the source table. So I expect that the number 7 results from 7 lines in the source table - And when I run an SQL query translated to use the same filter options as WHERE part, I do indeed get 7 lines matching the date and other settings I asked for. Everything ok so far.
When I execute the MDX query with DRILLTHROUGH I get only 3 lines as result - I remove the DRILLTHROUGH again and get 7 as result again... what can be the reason for this?
DRILLTHROUGH SELECT {[Measures].[Counter]} ON 0 FROM [Cube] WHERE ([Final Level].[Level Hierarchy].&[-6], [Action].[Action].&[4], [Submitted Date].[Submitted Date].[Submitted Year].&[2007], [LMU-SL].[LMU-SL Hierarchy].&[3])
Perhaps there are duplicate records at the measure group granularity, therefore in the cube you ended up with only 3 distinct records, but the total value is still correct - 7.|||Mosha Pasumansky wrote:
Perhaps there are duplicate records at the measure group granularity, therefore in the cube you ended up with only 3 distinct records, but the total value is still correct - 7.
Mosha, thanks for answering.
I understand what you mean, but I can confirm that this is not the reason / solution.
I did confirm that in fact the 7 rows are distinct for the granularity of the measure group. They each have their own primary key in the database, and the measure group is based on this table, on this pk.
I browse the cube in Excel, and there are more combinations like this one where a number of lines is counted in cube ("11" in this other case), 11 distinct lines can be confirmed using sql, but no line at all is returned for drill. If I create my MDX without drillthrough, I get "11" as value for the measure. If I put "drillthrough" before it - I get no results at all.
As always, it is all far more complicated, as you guessed... My original MDX showed 4 dimensions sliced. 3 of them are really dimension on the measure group, these dimensions are joined in as regular to the measure group. The 4th one is a dimension on a measure group with a finer grain, a deeper level of detail as I try to imagine it. This 4th dimension is joined to the finer grain as a regular dimension, and to the measure group queried using m-n joining "back up from finer detail level".
For information, I can display a row count on the detail measure group as well, and these numbers in the cube are also perfectly in line with tests done using sql. But drills to the detail group give no results at all (even if the cube showed some 10 (distinct) detail lines for this dimension, verified using sql.
I suspect the problem is around that m-n from a finer level, since drilling into both measure groups without using this dimensions mix from different grains works perfectly fine. I am quite sure my dimension - measure setup is correct, since all counts in the cube come out the same value as manual sql test comparisons.
I am really a bit worried here with the reliability of SSAS 2005.
I am now cleaning out the db to only host the 7 lines in question as all data available, opposed to 2.5 mill on the queried level and 10 mill lines in the finer grain section to see if that makes any change in the result, and reload the whole SSAS db with this greatly simplified amount of data. I might also use CTP of SP2 to see what happens.
|||I am now cleaning out the db to only host the 7 lines in question as all data available, opposed to 2.5 mill on the queried level and 10 mill lines in the finer grain section to see if that makes any change in the result, and reload the whole SSAS db with this greatly simplified amount of data.
I think I found out the worst I could imagine: With less data loaded, or better: only data that falls within the area I slice for, I get ALL my 7 lines as result in drill and as cube measure. I did not change any settings in the project or made any changes to the query. I only threw out around 12 mill lines of data from the source db... I really doubt the precision, or maybe better the reliability of SSAS now.
In case anyone wants to know I noticed the difference between the lines given back and not given back: I suspect the problem I have is somewhere along the aggregations build for the cube. Why? The lines that work are in one category of a dimension (a pretty simple one with the order state, 8 items, like in "ordered", "mailed", "received" or "returned" and so). Anyway, the lines that work are in one state, the ones that do not are in another state.
This dimension is NOT used in this example, and also not part of my MDX query, neither with or without the drillthrough part. I suspect there is no aggregation on this dimension since the design wizard did not call an 8 entry dimension worth it. Then again, I did not change the aggregation setup, I only cleaned the source db of other data...
I am SERIOUSLY in doubt now! Trying SP2 CTP now...
No comments:
Post a Comment