When are Implied Shares Created?
An Implied Share is a relationship between a parent member and its child member in the Application outline. Implied Shares are an Essbase feature that will also affect Planning users since Planning applications are built on top of Essbase.
The purpose of Implied Shares is to reduce the block size in Essbase by avoiding the unnecessary duplication of data. Implied Sharing is enabled by default.
There are three scenarios where an Implied Share relationship will be created between a parent and its child.
- The parent has only one child
- The parent has only one child that consolidates to the parent (the other children of that parent being non-aggregating)
- The parent is of data type "Label Only", in which case the parent will inherit the value of the first child, no matter what the aggregation settings of the children
Examples:
Assume all members are set to data type "Store"
Scenario #1
Parent A
Child 1 (+)
Scenario #2
Parent A
Child 1 (+)
Child 2 (~)
Child 3 (~)
In both of these scenarios, Essbase will automatically create an Implied Share relationship between Parent A and Child 1. This is done because the values of the parent and child in the above scenarios are always going to be the same, so storing two separate values in Essbase only increases block size unnecessarily.
When an implied share relationship is created, each implied member will assume the other member value. If a data value is entered for the parent, the child will assume the same value after a save (Planning Data Form) or after a lock, send and refresh (Excel add-in for Essbase).
If a data value is entered for the child, the parent will usually assume the same value after a save (Planning Data Form) or after a lock, send and refresh (Excel add-in for Essbase). There is one exception to this, explained below.
Unintended Effects on Planning Data Forms
Usually, the parent and child can be treated interchangeably. For example, if a Calculation Script or Essbase Load Rule is used to populate a parent or child in an Implied Share relationship, the other member will always assume the value of the member populated by the Calculation Script or Load Rule. The last value calculated or imported will "win", and become the value for both members. It is possible to refer to either the parent or the child as a variable in a Calculation Script and the result will be the same.
However, this is one situation in which the behaviour described above can interact with the particular design of a web form to produce unexpected results. If both the parent and child members are displayed on the same Planning Data Form, data entered for the child may be discarded when the form is saved, leaving that cell in the form empty, or displaying the "#missing" null value. Alternatively, the cell may revert to an earlier value, discarding changes made since the last save.
This situation arises because of the way that a data form is saved. During a save operation, the form is read line by line from left to right, with the top line read first. Since most Planning applications are "bottom-up" applications, data is typically entered for the child member (as the parent member is read only). This typically leads to the following sequence of events:
- The data form displays the child member above the parent, on the data form. This is the default layout for a data form: the parent is displayed on the row below its children, indented.
- The user enters data for the child member, which was previously null
- The data form is saved. The save operation reads the form left-to-right and top-to-bottom. Therefore the child is saved first and the newly entered data submitted to Essbase.
- The save operation then reaches the parent, which is still null (an empty cell). Because of the Implied Share, this null value overwrites the value of the child member, effectively discarding the data entered in step 2.
How to Avoid the Side Effects of Implied Shares in Planning
There are several ways to work around the issue outline above.
I. Use the "Never Share" setting
Set the parent member to use the "Never Share" storage setting, rather than "Store". This disables the implied share, so that the parent and child store their values separately.
A "Never Share" member differs from a "Store" member in one respect: a parent member set to "Store" will display the aggregated value of its children after a save (Planning Data Form), after a lock, send, and refresh (Excel add-in for Essbase), or after running an aggregation (running a Business Rule to aggregate the members on the form). A parent member set to "Never Share" will only display the aggregated value of its children after an aggregation is run.
It is usually advantageous for parents with single children to use the default storage type of "Store" (thus keeping the Implied Share relationship) as it reduces the block size and overall database size in Essbase, and improves calculation and aggregation times. Only use "Never Share" when actually required.
II. Add a Dummy Member
Add a dummy member to the outline as a second aggregating child. A dummy member need not be used on forms, but exists in the outline. This will disable implied sharing, since the parent member now has more than one aggregating child (see Examples section above).
Note that this workaround will not help if the parent is a "Label Only" member. "Label Only" parents have an Implied Share with their first child, no matter how many other aggregating children are present. The only way to disable implied sharing in such a scenario is to change the "Label Only" storage type.
III. Change the Design of the Planning Data Form
Do not include both parent and child on the same data form.
IV. Disable Implied Sharing Completely
Prior to version 11.1.1.0 this could only be done on a server-wide basis, so that all applications on the Essbase server would be affected. Since disabling Implied Sharing will have a negative impact on performance and database size this should not be done lightly.
Disable Implied Sharing for the entire Essbase server (9.3.1 and earlier)
- Back up all Essbase data as a precaution
- Shut down Essbase (stop the service)
- Edit the ESSBASE.CFG file and add the following line:
EVENT 29
- Start Essbase. Upon startup, Essbase internally eliminates the implied share optimization.
Note: do not use EVENT 29 with later versions! See the section below instead
Disable Implied Sharing on a per-application basis (Essbase 11.1.1.0 and above)
- Back up Essbase data as a precaution
- Shut down Essbase (stop the service)
- Edit the ESSBASE.CFG file and add the following line:
IMPLIED_SHARE [application name] FALSE
This will disable implied shares for this application. Omit the square brackets when entering the real application name.
If no application name is specified implied sharing will be disabled at the server level (the same effect as EVENT 29 in earlier versions)
- Start Essbase. Upon startup, Essbase internally eliminates the implied share optimization.
EVENT 29
IMPLIED_SHARE [application name] FALSE
This will disable implied shares for this application. Omit the square brackets when entering the real application name.If no application name is specified implied sharing will be disabled at the server level (the same effect as EVENT 29 in earlier versions)
