How to fail a feeder....

[Steve Rowe]

I'm just wondering if there is a best way to write a feed that will fail in a large proportion of cases.

I'm doing some fairly straight forward time series mapping to bring various forms of prior period data into the current month so that BI has some a nice simple structure to reference.

I have an attribute against period that gives me the period I need to feed to, 90% of the time these will blank.

Which form of the feeder will fail with the lightest load?

[]=> DB ( If (AttrsIsBlank, '' , 'CubeName') , !Dim1 , !Dimetc , AttrValue, !Dim10);

or

[] => DB ( 'CubeName' , !Dim1 , !Dimetc , AttrValue, !Dim10);

I assume it is the later because there is no If statement but I'm wondering if at runtime a DB with no cube name fails much faster than a DB with a blank reference. I can see the first form could make the calculation engine give up faster as there is no cube to perform the DB on.
The second reference could actually mean that an attempt to fire the feeder is made, only failing when the AttrValue is blank is encountered during execution, or does the engine not perform the feeder action if it knows one of the references is blank?

Probably splitting hairs but it would be good too know if anyone has done any fine testing at this level of detail..

Cheers,

[gtonkin]

Hi Steve,
I am not going to answer your question but ask you one.
Why would you not create a C level of all the items where the Attribute is not blank and use that on the left side - this way it would only feed from items in the list i.e. those with an attribute? Granted you would need a TI process to flatten and rebuild and may not suit where users change attributes before you can refire your rebuild process.

[Steve Rowe]

+1 for you...

A good suggestion, all the data is recast each month anyway so I'm not concerned about it having "live" issues.

Cheers,