Implied Sharing Issues

Scenario:

For members that have an implied sharing relationship, if a parent and child are displayed on the same Oracle Hyperion Planning form, only values entered for the parent are retained. In the following examples, Planning creates an implied share relationship between Parent A and Child 1 because the values of the parent and child are always the same. These examples assume that all of the members are set to the Store data type.

Example 1:

   Parent A 
        Child 1 (+) 

Example 2:

   Parent A 
        Child 1 (+) 
        Child 2 (~) 
        Child 3 (~) 

Because most Planning applications are bottom-up applications, data is usually entered for the child because the parent is read only. The typical sequence of events:

  1. The form displays the child, usually above the parent.

  2. New data is entered for the child.

  3. The form is saved. The save operation reads the form from left-to-right and top-to-bottom, so the child is saved first.

  4. The save operation then takes the last occurrence of the value in the grid (the bottommost, rightmost value), which, because of the implied share, overwrites the value of the child. The data entered for the child is discarded.

Solution:

Depending on the requirements for your Planning forms, you can use these methods to avoid implied shares.

  • For a parent and child on the same form: Add a dummy member as an aggregating child. The dummy member is included in the outline but is not used on forms. Implied sharing is disabled when the parent has only one aggregating child.

  • For a Label Only parent: An implied share exists with the first child member regardless of how many aggregating children are present. To disable implied sharing in this situation, change the Label Only storage type or avoid including the parent and child on the same form.

  • For a parent that can be set to Never Share: If necessary for your application, you can set the parent member to the Never Share storage setting. The Never Share parent functions similarly to a Store parent with multiple aggregating children. However, unlike a Store parent, a Never Share parent displays only the aggregated value of its children after an aggregation is run.

Note:

For parents with single children, using the default storage type of Store (keeping the implied share relationship) is usually advantageous, because doing so reduces the number of blocks that are created, the database size, and the calculation and aggregation times. Use Never Share only when necessary.

For detailed information on implied sharing, see the Oracle Essbase Database Administrator's Guide.