CX 10.1 rule compiler incorrect logical comparison
Posted: Mon Oct 14, 2013 3:17 pm
I'm not sure if this has come up before. I have a vague feeling it has but if so it wasn't fresh enough in my mind to save a whole lot of unnecessary pain and annoyance due to a bug in the rule compiler in CX 10.1 giving an erroneous error message and refusing to save a rule.
The following string comparrison of a DB() string value to element name reference throws an (incorrect) error of the type "incorrect logical comparison" and won't save the rule.
Doesn't make sense, nor should it as an element name must be a string and the DB reference is for a string value.
After much muttering, swearing, abuse of furniture, etc. it turns out that the error in the rule evaluation can be gotten around by reversing the order of the comparison. That is the following works and compiles no problem:
Note that if a similar comparison is the 2nd, 3rd etc logical comparison in the IF then the order of comparison doesn't seem to matter. If the comparison is for a string literal or another DB reference then the order doesn't matter, it only crops up it seems for a !dim reference. Plain stupid as an element name can't be anything but a string.
I don't have TM1 10.1 to test against but I assume this bug is probably there too. Anyone else banged their head against this bug before and know if it is fixed in 10.2?
The following string comparrison of a DB() string value to element name reference throws an (incorrect) error of the type "incorrect logical comparison" and won't save the rule.
Code: Select all
IF( DB( 'Input Cube', !Version, !Company, '!Division', 'Investment Year' ) @= !Year & <comparison 2 ...>
After much muttering, swearing, abuse of furniture, etc. it turns out that the error in the rule evaluation can be gotten around by reversing the order of the comparison. That is the following works and compiles no problem:
Code: Select all
IF( !Year @= DB( 'Input Cube', !Version, !Company, '!Division', 'Investment Year' ) & <comparison 2 ...>
I don't have TM1 10.1 to test against but I assume this bug is probably there too. Anyone else banged their head against this bug before and know if it is fixed in 10.2?