Database Reference
In-Depth Information
So, if we deny access to the Total Product Cost measure what will happen to any
calculated members that depend on it? Here's a screenshot to show us:
Since one of the measures needed to perform the calculation is not available, the
result of the calculation will not be accessible through the role. Nevertheless, the
value displayed is very different from what we saw with Cell security.
The cube returns #VALUE , which indicates that there is an error in the definition of the
calculated measure, which is strictly speaking, true - the Total Product Cost measure
does not exist as far as this role is concerned.
One possible approach for avoiding this problem is outlined here: http://tinyurl.
com/ChrisDimSecurity , but this is rather complex. An alternative would be to
adapt the Date Tool technique from Chapter 5 , Handling Transactional-Level Data , and
create a new, empty physical measure group containing real measures whose value
we can overwrite with MDX Script assignments, as described at http://tinyurl.
com/SSAS-MeasureTool .
When is security evaluated?
More details on when security is evaluated during the cube initialization
process can be found at http://tinyurl.com/moshascriptinit .
The basic rule is that dimension security is evaluated before the MDX
Script is evaluated, and cell security is evaluated after the MDX Script.
This means that it is safe to reference named sets and calculated
members in cell security expressions, but not in dimension security
expressions. This is a simplification of what actually happens, however:
in some cases it does appear to be possible to reference MDX Script
objects from dimension security expressions but it can lead to some
unexplained behavior so we do not recommend doing this.
 
Search WWH ::




Custom Search