FIX on a UDA

Question

I am trying to FIX on a UDA for the 'Period' dimension. The UDA is defined as either 'open' or 'closed'. The dimension is re-built dynamically each night. When some periods are 'open' and others 'closed', this MAXL works. However, when all periods are 'open' - and there are not any 'closed' periods, the FIX statement doesn't operate as expected and the MaxL runs everything under the FIX. Very odd. Can anyone shed any light on this and offer their best work-a-round? Thxs.
FIX (@UDA("Period", "closed"))
     CLEARDATA "Forecast";
     DATACOPY "Actual" TO "Forecast";
ENDFIX;

Answer 1

Hello There.
Cameron:
I should have been more clear in my original posting.
The intent of the suggestion/alternative was from an "ease" of maintenance (and avoiding the "global fix" problem) perspective rather than a speed/performance one.
Regarding the FIX on the sub vars you are absolutely correct -- it will not make it any faster -- but you could prevent the script from executing the statements within the FIX by using sub vars rather than UDAS (actually you could also create an "opposite" UDA like "open" and use AND/OR/NOT logic within the FIX signature itself if you didn't want to go down the sub var path for whatever reason). As you know the problem the user is having is when there are no UDAs on the members of the period dimension the statements within the FIX execute (older version of essbase and setting option not being available). I was simply stating that you could use sub vars to specify only those months (assuming months are the base level members of the period dimension) that you want the enclosed fix code to operate on -- of course you could/would need another sub var to specify the months to specifically exclude (e.g. &ActMonths, &FcstMonths) and possiibly AND/OR operator within the FIX statement itself if you like. The bottom line is you would make certain each member was always tagged with one of the two sub vars (again - could be done with udas) thereby allowing the script to only operate on those periods that it should. I just looked at the users second entry and it appears the second UDA and conditional route was taken.
In my opinion, a single substitution variable that evaluates to 1 - 12 months (modified in one place - the sub var value-string itself) seems easier than manually or via load rule changing (potentially) up to 12 different period base level members -- once again assuming the base level members are indeed months.
And yes you are correct - datacopy does not work within a conditional -- it would have to be accomplished through another means which I now see the user chose -- and yes you are also correct in that datacopy is very fast and would likely be the hands-down most efficient means.
Gary:
With regard to the "Golden Rule" statement -- it was not my intention to imply that it is a "always do this or perish" rule (although - admittedly - using the term "golden" probably made it appear quite the contrary) -- given the fact that rarely is anything always black/white when it comes to hyperion essbase, particularly in the realm of database calculation optimization. Nevertheless, someone should tell the numerous hyperion instructors/technical consultants (including Ed Roske as he has it clearly stated in his Look Smarter book) that I have worked with in the past. Thanks for the food for thought -- I sincerely appreciate it.
Look Smarter excerpt: "...It is a good rule that can be used even more effectively..."
Outdated/misguided logic below? You decide sports fans...
In general, you should try and only use "FIX" statements on SPARSE dimensions.
FIX statements allow you to take a slice of the database and only perform an action on that slice. If you fix on a SPARSE dimension, then you are limiting the amount of blocks that you are performing the action upon. If you FIX on a DENSE dimension, you are not limiting the number of blocks, but rather just a portion within each block. Using the FIX statement on a dense dimension can cause multiple passes through the same blocks which is very inefficient. On the other hand, the IF statement is well suited to DENSE dimensions because it performs IF logic while the block is in memory.
Example: If JUL then ..., else .... will all be performed in one pass without the need of multiple passes through the blocks. In general, try and use FIX on sparse dimensions and IF on dense dimensions.
Thank you both once again for your comments.
Regards,
todd rebner
http://www.advancedepm.com/
Edited by: todd rebner on Jun 7, 2009 10:32 AM