The number of bits needed by a dimension is the maximum number of bits used by any level 0 child, including the level 0 children in alternate hierarchies and associated attribute dimensions. For the purposes of member numbering, attribute dimensions are treated as alternate hierarchies of their base dimensions.

In general, the formula to determine the number of bits required for any member in a dimension can be expressed as:

#_bits_member’s_parent + log(x)

where x is the number of children of the parent.

For example, if the member’s parent is member A, which requires 5 bits, and A has 10 children, the number of bits required by each child is:

5 +log(10) = 9 bits

The top member of a dimension or hierarchy usually uses 0 bits. However, when one or more top generations consist of label-only members, the label-only members do not receive member numbers (because they are not considered stored members). Therefore, if there are x members in the first non-label-only generation, those members use log(x) bits. The rest of the children below them are numbered normally.

Similarly, if a dimension or hierarchy is dynamic, only the level 0 members that are stored or shared receive member numbers. The number of bits required for those members is log(x), where x is the number of level 0 members that are stored or shared (that is, the number of level 0 members that are not formula members).

If, however, any alternate hierarchies have stored (non-shared) level 0 members, each member of every hierarchy in the dimension (including associated attribute dimensions) uses an extra log(x) bit, where x is the total number of hierarchies and associated attribute dimensions for this base dimension.

The following example uses the Products dimension in the ASOsamp.Basic database:

The Products dimension has two hierarchies: All Merchandise and High End Merchandise, which is an alternate hierarchy. High End Merchandise has one stored level 0 member: Stored Member. The Products dimension does not have any associated attribute dimensions.

Members All Merchandise and High End Merchandise use log(2) = 1 bit.

The calculation of the number of bits required by each level 0 children:

All Merchandise = 1 bit
   Personal Electronics, Home Entertainment, Other = 1 + log(3) = 3 bits
      Digital Cameras/Camcorders, Handhelds/PDAs, Portable Audio = 3 + log(3) = 5
         Children of Digital Cameras/Camcorders = 5 + log(3) = 7
         Children of Handhelds/PDAs = 5 + log(3) = 7
         Children of Portable Audio = 5 + log(2) = 6
      Televisions, Home Audio/Video = 3 + log(2) = 4
         Children of Televisions = 4 + log(5) = 7

         Children of Home Audio/Video = 4 + log(4) = 6
      Computers and Peripherals = 3 + log(1) = 3 **
      Systems, Displays, CD/DVD drives = 3 + log(3) = 5
         Children of Systems = 5 + log(2) = 6
   High End Merchandise = 1 bit
      Flat Panel, HDTV, Stored Member = 1 + log(3) = 3 bits

Member Computers and Peripherals has the same number of bits (3) as its parent Other.

The maximum bits used by any level 0 children in the Products dimension is 7 (Children of Digital Cameras and Children of Televisions). Therefore, Products uses 7 bits, which is less than the dimension size limit of 64 bits.

If the dimension size exceeds 64 bits:

• Essbase generates the following error when saving the outline:

  Hierarchy [DimensionName] is too complex. It exceeds the maximum member number width of 64 bits. See application log for details.

• Essbase logs messages similar to the following messages in the application log:

  Member number for member [level0member] requires [65] bits to encode
  Member [level0member] contributes [5] bits to member number
  Member [level1parent] contributes [20] bits to member number
  Member [level2parent] contributes [20] bits to member number
  Member [level3parent] contributes [20] bits to member number

To fix the error, use one of these recommendations:

• If possible, delete some siblings of any of the members referenced in the messages. Reducing the number of siblings by a power of two saves one bit. For instance, assume that level0member, which contributes 5 bits to the member number, has 18 siblings, including itself. Reducing the number of siblings to 16 or fewer saves one bit because log(16) = 4. Similarly, reducing the number of siblings to 8 or fewer saves two bits.

• Reclassify some siblings of members referenced in the messages. For example, move half of level0member’s 18 siblings to another parent that doesn’t have as many children. Alternately, create a new parent as a sibling of level1parent and move half of level1parent’s children under the new member. This approach saves one bit.

• Combine some intermediate levels. For instance, move level0member, and all of its siblings, to be children of level2parent and then remove level1parent. This approach is more involved but it can save many bits.