Options for How Members Store Data Values
You can determine how and when Essbase stores the data values for a member. For example, you can tell Essbase to calculate the value for a member only when a user requests it, and then discard the data value.
Each available member storage property is described as follows.
Table 5-4 Choosing Storage Properties
Storage Property | Behavior |
---|---|
Store |
Stores the data value with the member. |
Dynamic Calc |
Does not calculate the data value until a user requests it, and then discards the data value. |
Label only |
Label Only members are for grouping or labeling other members. No data is stored in the database for Label Only members. |
Shared member |
Shares values between members. For example, in the Sample Basic database, the 100-20 member is stored under the 100 parent and shared under Diet parent. |
Never share |
Does not allow members to be shared implicitly. Members tagged as Never share can only be explicitly shared. To explicitly share a member, create the shared member with the same name and tag it as shared. |
To set member storage properties using the Essbase web interface, open the outline for editing, select a member, and edit its general properties. Change Data storage type as appropriate. For more information, refer to Set General Properties.
If you are using an application workbook or Cube Designer to set the member storage properties, update the STORAGE property with the relevant code, next to each member on the appropriate dimension worksheet. S is for stored, X is for Dynamic Calc, O is for label only, and N is for never share. For more information, refer to Understanding Dimension Worksheets.
Stored Members
Stored members contain calculated values that are stored with the member in the Essbase database after calculation. By default, members are set as stored.
Dynamic Calculation Members
When a member is Dynamic Calc, Essbase does not calculate the value for that member until a user requests it. After the user views it, Essbase does not store the value for that member.
Essbase automatically tags members of attribute dimensions as Dynamic Calc. You cannot change this setting.
Refer also to Dynamic Calculation of Data Values.
Label Only Members
Label only members in Essbase have no associated data. Use them to group members or to ease navigation and reporting from Smart View. Typically, you should give label only members the "no consolidation" property.
You cannot associate attributes with label only members. If you tag a base dimension member that has attribute associations as label only, Essbase removes the attribute associations and displays a warning message.
A descendent of a label only member cannot be tagged as Dynamic Calc. In the following example, when verifying the outline, Essbase issues an error message indicating that ChildB cannot be tagged as label only:
ParentA = Label Only
ChildB = Label Only
DescendantC = Dynamic Calc
Tagging DescendantC as Store Data resolves the issue.
Shared Members
Essbase shared members can help you calculate the same member across multiple parents in the outline, which can be useful when an item belongs to more than one category. The data values associated with a shared member come from another outline member with the same name, called the prototype member.
The shared member stores a pointer to data contained in the prototype member, and the data is stored only once. To define a member as shared, a prototype member of the same name must exist. For example, in the Sample.Basic database, the 100-20 member under 100 stores the data for that member. The 100-20 member under Diet points to that value.
Shared members typically are used to calculate the same member across multiple parents; for example, to calculate a Diet Cola member in both the 100 and Diet parents.
Using shared members lets you use members repeatedly throughout a dimension. Essbase stores the data value only once, but it displays in multiple locations. Storing the data value only once saves space and improves processing efficiency.
Read the following sections to learn more about shared members.
Note:
Members with the same name may be duplicate members instead of shared members. See Duplicate Member Names in Outlines.
Guidelines for Shared Members
Essbase shared members must have no children, UDAs, attributes, or formulas. They must be in the same dimension as their prototypes, and follow after them in the outline order. Shared members can have unique aliases, and they can have the same name as other members.
Follow these guidelines to avoid errors when creating shared members:
-
Shared members must be in the same dimension as their prototype member. For example, both 100-20 members in the Sample.Basic database are in the Product dimension.
-
The prototype member must precede the shared member in the outline order.
-
Shared members cannot have children.
-
An unlimited number of shared members can have the same name.
-
UDAs or formulas cannot be assigned to shared members.
-
You can create a shared member for a member with a duplicate member name.
-
Attributes cannot be associated with shared members.
-
If accounts properties are assigned to shared members, the values for those accounts properties are taken from the prototype member, even if the accounts properties on the shared member are changed.
-
Aliases can be assigned to shared members.
-
If an alias for a shared member is empty, Essbase uses the stored member’s alias.
-
If you assign an alias for a shared member and you change the alias for a prototype member, the shared member’s alias doesn’t change.
-
A prototype member must be located before its shared member.
-
Avoid complex relationships between prototype and shared members that will be part of an attribute calculation, or a calculation may return unexpected results. See Attribute Calculation and Shared Members.
-
You cannot place a shared member and its prototype member under the same parent. In a duplicate member outline, siblings must be unique.
-
In grid clients (for example, Smart View), shared members can easily be differentiated from their prototype members, because you can specify for them to be displayed with a qualified name (for example, [Parent].[Child]). Shared members can be displayed with qualified names even if you have not set the outline to enable duplicate member names. Additionally, you can use qualified member names to search for shared members in the grid or using member selection.
Shared Member Retrieval During Drill-Down
During zoom in (drill-down) operations, Essbase retrieves prototype members instead of shared members, when available. Zooming out (drill-up) on a shared member retrieves the shared member parent rather than the prototype.
Essbase retrieves shared members during drill-down, depending on their location in the spreadsheet or grid client. Essbase follows these rules during grid retrieval:
-
retrieves prototype members (not their shared members) by default.
-
retrieves from the bottom of a spreadsheet first.
-
If the parent of a shared member is a sibling of the prototype member of one of the shared members, retrieves the prototype member.
Example of Shared Members from a Single Dimension
If you create a test dimension with all shared members based on the prototype members of the dimension East from the Sample.Basic outline, the outline would be similar to the one shown in Figure 5-1:
Figure 5-1 Shared Members from a Single Dimension

Zooming out on a shared member returns the shared parent, not the prototype member. For example, if you zoom out on Florida, Essbase returns the shared parent, test
.
If you retrieve only the children of East, all results are from prototype members because Essbase retrieves prototype members by default.
If, however, you retrieve data with the children of test above it in the spreadsheet, Essbase retrieves the shared members:
New York
Massachusetts
Florida
Connecticut
New Hampshire
test
If you move test
above its last two children, Essbase retrieves the first three children as shared members, but the last two as prototype members. Similarly, if you insert a member in the middle of the list above which was not a sibling of the shared members (for example, California inserted between Florida and Connecticut), Essbase retrieves shared members only between the nonsibling and the parent (in this case, between California and test).
Example of Retrieval with Crossed Generation Shared Members
You can modify the Sample.Basic outline to create a shared member whose prototype member counterpart is a sibling to its own parent, as shown in Figure 5-2:
Figure 5-2 Retrieval with Crossed Generation Shared Members

If you create a spreadsheet with shared members in this order, Essbase retrieves all the shared members, except it retrieves the prototype member West, not the shared member west:
West
New York
Massachusetts
Connecticut
New Hampshire
test
Essbase retrieves the members in this order because test
is a parent of west
and a sibling of its prototype member counterpart, West
.
Implied Shared Members
If implied sharing is enabled, parent members implicitly share the value of their single child members (when there is only one), or of their only consolidating child (when there is only one that consolidates, meaning it has an operator other than ~
or ^
).
Such parents are implied shared members, unless:
- they have a formula
- they are set to Never Share
- implied sharing is not enabled
By default, implied sharing is not enabled. Starting in Essbase 21c, you can enable it as needed using IMPLIED_SHARE_ON_CREATE configuration setting.
If implied sharing is enabled, Essbase assumes (or implies) a shared member relationship in the following situations:
-
A parent has only one child. In this situation, the parent and the child contain the same data. Essbase ignores the consolidation property on the child and stores the data only once—thus the parent has an implied shared relationship with the child. In the following example, the parent 500 has only one child, 500-10, so the parent shares the value of that child:
500 (+) 500-10 (+)
-
A parent has only one child that consolidates to the parent. If the parent has four children, but three are marked as no consolidation, the parent and child that consolidates contain the same data. Essbase ignores the consolidation property on the child and stores the data only once—thus the parent has an implied shared relationship with the child. In the following example, the parent 500 has only one child, 500‑10, that rolls up to it. The other children are marked as No Consolidate(~), so the parent implicitly shares the value of 500‑10.
500 (+) 500-10 (+) 500-20 (~) 500-30 (~)
The cases above do not apply when the parent member has a formula.
If you do not want a member to be shared implicitly, mark the parent as Never Share so that the data is duplicated instead.