Zero suppression in a TurboIntegrator process affects member ordering in a view

When you turn on zero suppression in a TurboIntegrator process, data in a view is ordered by when members (elements) were added to the dimension, instead of by the default dimension order (alphabetical) or by the defined subset order.

When a TurboIntegrator process is created with the parameter pSuppressZero = 0 (suppress zero is turned off), it shows data for the dimension in descending alphabetical order or by the defined subset order, as expected. When a TurboIntegrator process is created with the parameter pSuppressZero = 1 (suppress zero is turned on), it shows data for the dimension in the order that the members were added to the dimension.

This is an as-designed limitation based on the different types of cube data iteration associated with the suppress zeroes property on the view.

When zero suppression is off, TM1 performs an "expanse iteration" of the base cube data that visits all possible locations implied by the metadata. This type of iteration can be prohibitively slow.

When zero suppression is on, TM1 instead performs a "population iteration" that is driven by where actual data resides. This type of iteration can be much faster. However, the expanse iteration works by using member sorting indexes, while the population iteration uses member data coordinate indexes (of necessity, since that is how the data is stored.) When a new member is added, the sorting indexes of the members are reassigned to implement alphabetical ordering based on the member name. But the new member must also be assigned a new data coordinate index. This index will be above the existing range of data indexes that are already established at that time. This is the main reason for the difference in behavior.

This problem can be resolved by performing a TM1 database restart. After the database restart, the dimension will be freshly loaded into memory, at which time the sorting indexes and data coordinate indexes will match.