Rule editors [] =[]

[Chengooi]

I was trying this line ['Oct-08','Actual'] =>['Oct-08','Test']; in rule editor and did not give me any result at all.
Can someone tell me what 's wrong with that line.
The cube has 5 dimensions of which these 2 dimensions were specified in the rule, the other 3 simply ALL.
Please help!

[ScottW]

are you trying to write a rule or a feeder?

[Steve Rowe]

Skipcheck;

['Oct-08','Test'] =N: ['Oct-08','Actual'];
Feeders;
['Oct-08','Actual'] =>['Oct-08','Test'];

Should get to where you want to be. If your struggling with the basics can I suggest the rules guide that come with the product?

Cheers,

[Chengooi]

Perfect , Thanks very much!

[Chengooi]

I was trying to find help for what this line actually do, was it to initialise the element actual ?
['Oct-08','Test'] =N: ['Oct-08','Actual'];

[Alan Kirk]

I was trying to find help for what this line actually do, was it to initialise the element actual ?
['Oct-08','Test'] =N: ['Oct-08','Actual'];

I'm not following you.

The purpose of a rule is to calculate an "area" (range of values) of the cube based on values stored in another area of the cube (or other cubes), as well as possibly some constants or mathematical functions.

That means that in the line that you've cited, any cell in the cube which contains the elements "Oct-08" and "Test" will return the same values as a cell which uses "Oct-08" and "Actual" in the corresponding dimensions. Since you've specified "N:", This will only be true for N level values; consolidations will be calculated normally.

So in a 5 dimensional cube where those two are the first dimension, you'll end up with a situation where:
DBRW("YourCube", "Oct-08","Test","Dim3Element1", "Dim4Element1", "Dim5Element1")
will return exactly the same value as
DBRW("YourCube", "Oct-08","Actual","Dim3Element1", "Dim4Element1", "Dim5Element1")

and

DBRW("YourCube", "Oct-08","Test","Dim3Element1", "Dim4Element1", "Dim5Element2")
will return exactly the same value as
DBRW("YourCube", "Oct-08","Actual","Dim3Element1", "Dim4Element1", "Dim5Element2")

and so on for every N level element in dimensions 3, 4 and 5.

There's nothing to "initialise"; in that rule you're simply telling TM1 that you want to use the "Actual" values to populate the corresponding "Test" values. Actual is the element that you're drawing from, it's Test that's calculated. If this rule is applied, you'll still be able to make entries to the Actual element, but not the Test one.

As per Steve's suggestion, it might be an idea to work through the Rules manual; all of us cut our teeth on the Fishcakes examples at some point. David Friedlander did a good job of explaining how they work.

[Chengooi]

Thank you Alan for your excellnet explaination.
My real experience with thsi particular rule was:
I started the line :
Feeders;
['Oct-08','Actual'] =>['Oct-08','Test'];
Thinking that will map all n element of Oct, actual to all n oct-08 test.
But it did not work, so I posted the question and I was told to use

add one line at the begining, so I thought that was initialised line.

['Oct-08','Test'] = N: ['Oct-08','Actual'];

As soon as I added that line, I get Bob's your uncle, so I could not undersatnd why we need 2 lines to get it worked as per se.
what you have explained was ['Oct-08','Test'] = N: ['Oct-08','Actual']; what about the second line below feeder why is it required.
I understood the manual but I am also confused by it.

[Alan Kirk]

I started the line :
Feeders;
['Oct-08','Actual'] =>['Oct-08','Test'];
Thinking that will map all n element of Oct, actual to all n oct-08 test.
But it did not work, so I posted the question and I was told to use

add one line at the begining, so I thought that was initialised line.

['Oct-08','Test'] = N: ['Oct-08','Actual'];

As soon as I added that line, I get Bob's your uncle, so I could not undersatnd why we need 2 lines to get it worked as per se.
what you have explained was ['Oct-08','Test'] = N: ['Oct-08','Actual']; what about the second line below feeder why is it required.
I understood the manual but I am also confused by it.

Imagine that you have a cube which doesn't have any feeders in it. (It's possible to write cubes without feeders, but in MOST cases it's not a good idea. There are a handful of exceptions that we won't go into here.)

When TM1 calculates a view of a cube which has rules but no feeders, it would need to calculate EVERY cell in that view just in case that cell might be affected by a rule. Most of the time you don't even need to think about this; if you calculate a zero-supressed view in a cube which has no rules, then you'll get only cells with values in them. However if there are rules and you've elected not to use feeders, TM1 needs to look at every zero value as well... just in case it might need to be calculated.

This obviously slows it down quite a lot.

The alternative is to use a statement called SkipCheck at the head of your rules, which tells TM1 to only look at cells which it knows have a value.

How does it know whether cells have a value? In the case of cells which aren't affected by rules, then there's either a value already there from data entry, or there isn't.

In the case of cells which ARE affected by rules, you need to use a feeder. A feeder is where you take one of the rules formula values, and "push" it (or more precisely push a "flag") to the cells which are affected by the rule. This flags the cell as "needing calculation".

So in your case, any cell which contains the combination of the "Oct-08" and "Actuals" elements will "feed" the corresponding "Oct-08", "Test" cell. In this way, the TM1 server knows that when you calculate a view, it needs to make sure that it has calculated any of the "Test" elements that the view may contain, but it doesn't have to worry about any of the other cells unless they have values from data entry.

[Chengooi]

I think I am leass confused now, but really grateful to your reply Alan !

[Martin Ryan]

There is now a Feeders 101 post in Olapedia here. This may help clarify things a bit.

Martin