MembersWithData (Dimension Interface)
The MembersWithData property of the Dimension interface determines which members in a dimension can have associated data in the fact table.
Applies To
Data Type
Access
Access depends on the value of the ClassType property of the object.
| Class type | Access |
|---|---|
| ClsDatabaseDimension | R/W* |
| ClsCubeDimension | R |
| ClsPartitionDimension | R |
| ClsAggregationDimension | R |
* Read/write for objects of ClassType clsDatabaseDimension with a SubClassType of sbclsParentChild or sbclsMining, read-only for all other objects.
Remarks
When a nonleaf member has associated data in the fact table, a processing error occurs if this property is equal to dataforLeafMembersOnly. Otherwise, that nonleaf data is associated with a system-generated leaf member. Depending on the property setting, this system-generated data member may or may not be visible on query axes and in schema rowsets.
By default, the data for nonleaf members is aggregated with the values of the regular children of that member. This behavior can be overridden by defining a custom rollup function for the member (or the entire level). The system-generated data member is always available through a Multidimensional Expressions (MDX) statement by way of the <Member>.DataMember syntax. (This syntax returns the original member if that member is already a leaf.)
Consider the example of a cube based on human resources data. If a parent-child dimension contains all of the employees of an organization, a problem will exist in tracking the salaries for people at higher levels of the organization's hierarchy. Their salaries will be an aggregate of the salaries of the people who report to them (that is, the value of their member will be the aggregate of all the children of that member). By setting the value of this property to DataForNonLeafMembersHidden, you can build a cube in which nonleaf members of the dimension will also have data.
Using this method may present a problem, however, because the numbers for nonleaf nodes no longer add up as might be expected. You can solve the problem by setting this property to DataForNonLeafMembersVisible. In this scenario, the members at each level contain the correct numbers for the aggregation, but the data for that individual member is available under the DataMember property.