Business Rule - How to create blocks different techniques (Fix statement) - Part 2

Hi,

In my previous post here we discussed about different ways of creating blocks. In this post we would be discussing about how FIX statement would help to solve block creation issue.

The FIX statement definition is; it brings the block in to the memory for calculation.

Normally, we fix the intersection where we need to calculate the data or at-least this is what I even I do and have understood during the discussion with other Hyperion guys.

In this post, I am suggesting to FIX the intersection where the data is present and inside the FIX command have the intersection where the data need to be calculated.

For this lets have a simple test. Let's create a simple script as below.

Let's execute the script.

The script ran successfully but no Message popup was received

Now, lets input some value in this intersection

Now lets execute the script and check the results

The script was executed and it popuped up the Member name.

So what do we conclude here, during our first execution the commands (@RETURN) were ignored.

So why was it ignored? It was ignored because there was no block for that intersection and FIX statement could not bring in the blocks for calculation and hence the calculation was not executed. In the second run we forcefully created the block and FIX was able to bring in the blocks and the @RETURN command was executed.

Now, lets take an example from the Oracle document for @CREATEBLOCK.

The @CREATEBLOCK statement is inside a Dense member block and as per the Oracle document it should create the blocks for the "100" member. But when we apply in real time it doesn't work.



Why it doesn't work? Is the documentation wrong? or something we are missing?

Lets read the example again The example given below clearly states that it assumes the data has be loaded into the block for 100-10 and New York.  That means they are fixing the intersection where the data is loaded and hence the command below gets executed and it creates the block for the "100" member.

Summarizing the above post (purely my observation and views);

• FIX on the intersections where the data is missing or rather block is missing, ignores the command and the calculation is not executed since no blocks are being brought into memory for calculation
• Suggestion is to FIX on the intersection where the data is already present and in the command section have the intersection where the data needs to be calculated this will solve the block creation issue with out any additional effort to create the block. (I know sometimes it would be difficult to have this situation where you would FIX on the intersection that is when you need to use the other block creation methods)

Hope you find this helpful;

Thanks :)