Implied Sharing Issues

Scenario:

For members that have an implied sharing relationship, if a parent and child are displayed on the same 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.

Note that, 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.