TM1 Forum

Hi ,

I have two dimensions in a cube :
Dim1
-> Total
-> Elem1
-> Elem2
-> ...
-> Elem100

MeasureDim
-> MeasureString (as string)
-> Measure1 (normal decimal)

I have a rule like this: ['Measure1'] = numbr( db('cube', 'Total', 'MeasureString' ));
This simply "copies" the string (converted to integer) found at the Total consolidation to all leaves.
I suspect I have to write a feeder for this. But I am not sure how ... My first idea is
['MeasureString', 'Total'] => ['Measure1', 'Total']
Can someone confirm this way of writing the feeder?

fabpas wrote: ['Measure1'] = numbr( db('cube', 'Total', 'MeasureString' ));
This simply "copies" the string (converted to integer) found at the Total consolidation to all leaves.
I suspect I have to write a feeder for this. But I am not sure how ... My first idea is
['MeasureString', 'Total'] => ['Measure1', 'Total']
Can someone confirm this way of writing the feeder?

Yes. That's exactly how you would do it.

I don't think that will do what you need.

Feeder always fire from the children of the parent specified, so unless any of the 100 children for MeasureString Total have anything in them it won't fire.

Also if for some reason you do have something in one of those 100 elements it will fire to all 100 elements each time for Measure1, so again not desirable.

You are better of creating a new element call Elem 0, which sits outside the consolidation and then use this to fire to the target i.e. This would fire 1 -> 100

['MeasureString', 'Elem 0'] => ['Measure1', 'Total']


hiraniha

hiraniha wrote:Feeder always fire from the children of the parent specified, so unless any of the 100 children for MeasureString Total have anything in them it won't fire.

Also if for some reason you do have something in one of those 100 elements it will fire to all 100 elements each time for Measure1, so again not desirable.

You are better of creating a new element call Elem 0, which sits outside the consolidation and then use this to fire to the target i.e. This would fire 1 -> 100

['MeasureString', 'Elem 0'] => ['Measure1', 'Total']

You are right for numeric data. But the OP isn't feeding from a numeric consolidation but from a string cell. Strings don't consolidate, for string data all cells are effectively leaves. So the concept of feeding from the consolidation Total in dim1 string measure intersection will work perfectly as is and will feed all the N element numeric measure cells that roll into Total. There is absolutely no need to have a separate technical element.

Whether this measure would need to be fed at all is a different matter, I only answered the OP's question if the suggestion would work. For "lookup" type metrics like this that have no need themselves to consolidate there is a good argument that they don't need to be fed at all, or they could be fed from an appropriate leaf that contains numeric data rather then feeding all children from the parent.

Hi lotsaram,

You had me intrigued as I never knew that about strings, so I tried it, and it didn't work on 10.2.2 FP1. Suppress zero suppresses all values in Measure1, but if I put a value in any of the items 1..10 for MeasureString the feeder fires and feeds as expected. I would love to understand your reason for why you thought it would work as the concept could prove useful sometimes.

hiraniha

You haven't switched on feeding from/to strings. FEEDSTRINGS is needed either line before or line after after SKIPCHECK.

That should then work as per your test DB. If it doesn't then BUG! ... as strings should feed directly as per definition any string cell is a "leaf".

lotsaram wrote:You haven't switched on feeding from/to strings. FEEDSTRINGS is needed either line before or line after after SKIPCHECK.

Interesting. My understanding has always been that FEEDSTRINGS is used to feed to strings, but not to feed from strings. I think I'll run some tests. This could be another new finding for me after the recent discovery that FEEDSTRINGS can come after SKIPCHECK.

qml wrote:My understanding has always been that FEEDSTRINGS is used to feed to strings, but not to feed from strings. I think I'll run some tests.

Well, actually mine too. But I have always been in the habit of including FeedStrings whenever I have a rule that has string measures. Call it the precautionary principle.
Do you agree though that a string at a consol of a business dimension if feeding he same C node but a numeric measure should feed directly to the consol (and therefore feed all N descendants)? If not then this would seem a bug to me as I'm sure I've done this before and it has worked. A string at any level is a leaf.

lotsaram wrote:Do you agree though that a string at a consol of a business dimension if feeding he same C node but a numeric measure should feed directly to the consol (and therefore feed all N descendants)? If not then this would seem a bug to me as I'm sure I've done this before and it has worked. A string at any level is a leaf.

Yes, I agree with that. Although I do have a vague memory (could even be a fake memory) that there was a defect with this in some version. But that would have been maybe around 9.5.x, not 10.2.x.