My team built an SSAS cube a year or two ago; it was the second cube we've built. We rolled it out to a few teams who have been using it without any issues. Today, I sat down with a new user to set up the data connection in Excel and do a little training, and the user received a strange error:

DimensionPermission (1, 2) The '[J]' member was not found in the cube when the string, [Measures].[J], was parsed.

What's strange is that the member in the error message does not exist in this particular cube. It exists in the first cube our team built, but none of the calculations or queries in the second cube use members from the first cube. We used the first cube as a template for the second cube, but all the original measures/dimensions were overwritten or deleted.

As far as I know, no other users have seen this error including users in the same AD group. The security is pretty basic on the cube, AD groups are used in the database roles, nothing is dynamic and we aren't using MDX to specify security.

I've combed through the SSAS project in data tools, and I can't find any reference to this member. Does anyone have an idea of what might be going on here? This and this were the two common themes I found in my searches, but as I said before, everything from the first cube was overwritten or deleted, so I can't find anything in the cube that references the missing member.

1 Answer 1


In SSMS if you open each role and find the Measures Dimension Data security section then go to the Advanced tab (if you have trouble finding it see this blog for screenshots from the same screens in SSDT-BI) do you see any role mentioning that problem measure? If that measure doesn't exist in the cube then remove it from the security role definition.

If that doesn't help you find it then right click on the database on SSMS and script the database as an Alter then search the XMLA for that measure and post back the section of XMLA where you find it.

  • Found it! I had looked in Measures Dimension Data security for the role I thought was the issue. Turns out this user was also in an AD group as part of another role, and that's where the issue was. I was also able to see the problem member when I scripted the database. Thanks so much!
    – ARich
    Commented Jan 21, 2016 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.