Best option for not calculating other versions in cubes

[Duncan P]

The DB statement appears to be incorrectly determining that the string cell is STET, and reading the underlying value.

You can get round this but it is cumbersome.

Insert the line

Code: Select all

['String'] = S: IF( 0 = ELISANC('Version', 'Version History', !Version), DB('Source', !Version, !Year, 'String'), CONTINUE );

at the top of your rule. This reverses the condition and removes the STET from the expression that gives the string value.

I recognise that while this is possible in the simple example you gave it may not be practical in your real system.

[Duncan P]

Hi Harry,

What you need to do is to take the version of the rule with

Code: Select all

[] = S: IF( ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE );
[] = IF( ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE );

and rearrange it so that all your other S: statements are after your S: conditional STET and before your other conditional STET.

A bit like this

Code: Select all

[] = S: IF( ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE );
['String'] = S: DB('Source', !Version, !Year, 'String' );

[] = IF( ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE );
['Number'] = N: IF( DB( 'Target', !Version, !Year, 'String' ) @= 'True', 1000, -9999999 );

What was happening was that - within calculations only - the second conditional STET statement (the numeric one) was being applied to your 'String' cell. It matched on left hand side area definition but didn't match on datatype and so the cell was being left as STET, that is the value was read from the underlying cube data. This used to be the behaviour (in 9.4 and before) for both displayed values and also values used in calculations. It was changed for displayed values but not for values used in calculations, which would appear to have been an oversight.

In summary, if you keep all your S: statements above all your numeric statements you'll be fine.

Have a good weekend,
Duncan.

[qml]

Duncan, that is an incredible finding, thanks for sharing!

[BigG]

In 9.5.2 I found something similar with S: rules, they didnt work if any [<empty>] rule statements were prior to the rule, seem to stop string calculated values from being recognised by subsequent rule.

To resolve try ['String'] = S:

[harrytm1]

Hi Duncan,

Thank you so much! I have tested your suggestion and it now works correctly.

The funny thing is, prior to your suggestion, when I use "Trace Calculation" on the erroneous calculated numeric value, the calculated string value is indeed returned correctly as "True". The unresolved string value bug only surfaced at the top level of the Trace Calculation console. In other words, if you drill down to check on the resolution of string, it is actually resolved correctly.

I'm very surprised that this has not been highlighted before. I'm not sure if this problem exists since 9.4.1, but it does happen on 9.5.2 FP1 onwards to 10.1.

harry