Databases Reference
In-Depth Information
Of course, you can fix on any database member(s) you wish, and sometimes you will
have no choice. However, if calculation script performance becomes an issue, this is
one of the first places to look to make improvements.
For example:
FIX(Sparse Dimension)
IF(Dense Dimension)
Any Calculation Function;
ENDIF
ENDFIX
There is one caveat to this. Essbase will only
FIX
on members in blocks
that have been previously created. You can solve this by using the
CREATEBLOCKONEQ
command in your calculation script. This command
will create the necessary missing blocks for your sparse members.
When you use the
FIX
/
ENDFIX
command, you are basically turning on, and then off,
the data filtering that you incorporated using the
FIX
/
ENDFIX
command in the first
place. In a typical calculation script, you may have many separate instances of
FIX
/
ENDFIX
commands that enclose a wide variety of calculation functions. The
FIX
/
ENDFIX
commands can also be nested inside one another, much like nested
IF
/
ENDIF
statements. For every
FIX
statement, there must be a matching
ENDFIX
.
There is one critical thing you must know about nesting
FIX
/
ENDFIX
commands. Never fix on one level of a dimension, then fix again on a
different level of that same dimension in a nested
FIX
command.
Always attempt to
FIX
to the specific level you intend to for a dimension in one
FIX
command. The reason for this is because even though the next
FIX
command
is nested within the first
FIX
command it will still pull the entire dimension into
the calc pool for filtering. In the example of a bad implementation below, the first
FIX
command will select all members from the
Calendar Periods
dimension.
The second
FIX
command will select all of the zero level members from the
Calendar Periods
dimension. This will actually result in all members of the
Calendar Periods
dimension being calculated.
Do
not
do this:
FIX("Calendar Periods")
FIX(@LEVMBRS("Calendar Periods",0))
Any Calculation Function;
ENDFIX
ENDFIX
