Cube Wackiness – Two Different Internal Errors
A couple of weeks ago, I posted a blog entry that demonstrated my ignorance on how cube space was defined in SSAS. Starting my BI career with Essbase, I still think in the block storage mode used by that platform. One of the strengths that Essbase had was that attributes could be created on stored members without requiring the cube to be reprocessed. I thought that an SSAS attribute which had its AttributeHierarchyEnabled property set to False would behave identically. That thinking is incorrect and even disabled attributes help define the cube space.
That feature worked great for me at the time as what once was a disabled attribute, through a significant shift in reporting requirements, now needed to be enabled. Re-enabling the attribute and deploying the changes, surprisingly to me, did not require that the dependent cubes be reprocessed. However, I had made a serious PEBKAC error. I changed the AttributeHierarchyEnabled property on the database dimension and also in the cube dimension of only one of my cubes. I had a linked measure group to another cube where the attribute hierarchy wasn’t re-enabled. SSAS let me go on so I thought everything was okay.
This week a very simple query on the linked measure group was run using this newly re-enabled hierarchy that was still disabled on the source cube.
which returned the following:
Internal error: An unexpected error occurred (file ‘mdsubcube.cpp’, line 6260, function ‘MDSubcube::IsPartiallyCoveringCell’).
What’s also strange is when I changed the year from 2009 to 2010, a different error was returned.
Internal error: An unexpected error occurred (file ‘pfstore.cpp’, line 822, function ‘PFStore::CopyRecords’).
Apparently, when using linked measure groups, SSAS doesn’t like the situation when an attribute is enabled in one cube but not the other. When I enabled the attribute hierarchy in both cube dimensions, the errors were resolved.