TM1 9.5.2 vs. 10.2 rule behaviour for string values

[foogy]

Dear members,

I'm wondering if handling of string values in rules is not working properly in 9.5.2 (FP3) while it works as expected in 10.2 (FP1+IF1). I was confronted with the problem in 9.5.2 and then figured out that the same rule is working perfectly in 10.2 by copying the relevant objects to a test system of that recent release (did not check releases in between).

To stay as lean as possible, I've cut down my problem to a minimal example, which does not make much (business) sense without the whole context, but should ease up diagnostics:

• A rule shall carry forward a numeric value as well as a string value along a dimension of three elements ("Step 1", "Step 2", "Step 3"). In each step, there should take place some magic logics, but the logics are not causing the problem, so just forget about.
• Numeric and string value is entered in cube in Step 1 (see screenshots below). The rule shall just carry forward both values from Step 1 to Step 2, and from Step 2 to Step 3. That's it (at least in the minimal example outlining my problem).

As you can see in the screenshots below, the carry-forward works in 10.2, but does not work in 9.5.2: While the values are still carried forward to Step 2, they are not carried forward to Step 3.

Different behaviour in 10.2 and 9.5.2 for string values

rule_behaviour_strings.png (7.54 KiB) Viewed 3706 times

The simplified rule for this example is in both cases exactly the same:

Code: Select all

#Carry forward from Step 1 to Step 2
['Step 2'] =N: ['Step 1'];
['Step 2'] =S: DB('test_cube',!Dim1,!Dim2,!Dim3,!Dim4,!Dim5,!Dim6,'Step 1',!MeasureDim);

#Carry forward from Step 2 to Step 3
['Step 3'] =N: ['Step 2'];
['Step 3'] =S: DB('test_cube',!Dim1,!Dim2,!Dim3,!Dim4,!Dim5,!Dim6,'Step 2',!MeasureDim);

Is that a known behaviour in 9.5.2? If so, how else can I forward these string values? To my understanding, this has nothing to do with feeders, thus there is no FEESTRINGS and FEEDERS statement included. And in 10.2, it works as expected without such statements. I also tried to add FEEDSTRINGS and FEEDERS statement in 9.5.2 without success.

Is there any known configuration parameter in tm1s.cfg that might cause such a behaviour?

Thanks for any comments or ideas on that issue.

Update: just noticed in 9.5.2 FP3, that strings are carried forward as expected if I'm using ONLY =S: statements:

Code: Select all

#Carry forward from Step 1 to Step 2
['Step 2'] =S: DB('test_cube',!Dim1,!Dim2,!Dim3,!Dim4,!Dim5,!Dim6,'Step 1',!MeasureDim);
#Carry forward from Step 2 to Step 3
['Step 3'] =S: DB('test_cube',!Dim1,!Dim2,!Dim3,!Dim4,!Dim5,!Dim6,'Step 2',!MeasureDim);

Leads to the expected result for the string element:

Works fine if only =S: statements used

9.5.2_S_statements_only_OK.png (2.01 KiB) Viewed 3699 times

However, once adding any "=N:" statement will cause the string values fail to carry forward. May be this is a helpful information for anyone.

Regards,
foogy

[qml]

Have you tried putting the S rules before the N rules?

[foogy]

Have you tried putting the S rules before the N rules?

I've just tried that (by intuition) and found out that in this case, the strings are carried forward properly. I just wanted to update this post, however you already put the correct hint here

So may be I can at least proceed this way. But I'm still interested if there is any reason for that different behaviour. I mean in 10.2, it's working no matter of the order.
I just can imagine the following: the =N: statement matches both elements (as the are both N-elements). And once a rule matches, the remaining statements are not considered (usual behaviour). Still confusing...

So thanks for your immediate feedback. Further comments are still welcome, of course. I'm also interested if this behaviour is new with FP3 or if it already was the same with FP2. I cannot check this, all servers are already updated.

KR,
foogy

[Duncan P]

As QML is hinting, in version 9.5.2 and before an N: statement would prevent any following S: statement being processed for the cells that it covered, even those cells that are of type string.

Before version 10, it is necessary to put the S rules for any region before the N or C rules for that region.

An interesting example of this can be found in this thread.