TM1 9.4 Breaking Change - Rule derived Aliases
Posted: Mon May 04, 2009 6:05 am
Rule derived aliases cause errors in the retrieval of numeric and string attributes when a DBRA/ATTRS formula is referenced to the (rule-derived) Alias name. The errors also manifest in the properties pane of the Subset Editor. No changes are detected in the }ElementAttributes_<DimName> cube.
Aliases such as ['CodeDesc'] = !Account | ' - ' | ATTRS('Account', !Account, 'Desc'); result in the loss of the ability to return further element attributes when referencing an Alias created in this way.
Steps to re-create error (screen-shots attached):
Create dimension called DimBugTest with three elements;
eBugTest_01
eBugTest_02
eBugTest_03
Add two Aliases, one to be manually entered and one Rule derived;
DE_Alias
RUX_Alias
Add two string and two numeric attributes;
sAttribute_01
sAttribute_02
nAttribute_01
nAttribute_02
Add a rule to the }ElementAttributes_DimBugTest cube to create an Alias consisting of the Element name and an appended constant string expression;
['RUX_Alias'] = S: !DimBugTest | '_RuleAlias';
The attached screenshots show the results of this configuration. All attribute values are corrupted/lost when viewing the elements with the rule-derived alias switched on in the Subset Editor. ATTRS and DBRA formulas do not return any of the attribute values if the ElementName attribute passed to the function is the name of a rule derived alias.
NB: This behaviour is new in TM1 9.4.
This same example, in various forms, has been trialed on various versions of TM1 9.4 (x86 and x64 including on 9.4 MR1 FP1 HotFix6), on different physical machines with different operating systems. The results were consistent across all trials.
The same example has also been created on TM1 9.1SP4, 9.1SP2. 8.4.4. The error was not able to be replicated on any version other than 9.4. That is, in all of the older versions rule derived aliases behaved exactly the same way as manually entered ones with respect to the retrieval of string and numeric attributes.
Aliases such as ['CodeDesc'] = !Account | ' - ' | ATTRS('Account', !Account, 'Desc'); result in the loss of the ability to return further element attributes when referencing an Alias created in this way.
Steps to re-create error (screen-shots attached):
Create dimension called DimBugTest with three elements;
eBugTest_01
eBugTest_02
eBugTest_03
Add two Aliases, one to be manually entered and one Rule derived;
DE_Alias
RUX_Alias
Add two string and two numeric attributes;
sAttribute_01
sAttribute_02
nAttribute_01
nAttribute_02
Add a rule to the }ElementAttributes_DimBugTest cube to create an Alias consisting of the Element name and an appended constant string expression;
['RUX_Alias'] = S: !DimBugTest | '_RuleAlias';
The attached screenshots show the results of this configuration. All attribute values are corrupted/lost when viewing the elements with the rule-derived alias switched on in the Subset Editor. ATTRS and DBRA formulas do not return any of the attribute values if the ElementName attribute passed to the function is the name of a rule derived alias.
NB: This behaviour is new in TM1 9.4.
This same example, in various forms, has been trialed on various versions of TM1 9.4 (x86 and x64 including on 9.4 MR1 FP1 HotFix6), on different physical machines with different operating systems. The results were consistent across all trials.
The same example has also been created on TM1 9.1SP4, 9.1SP2. 8.4.4. The error was not able to be replicated on any version other than 9.4. That is, in all of the older versions rule derived aliases behaved exactly the same way as manually entered ones with respect to the retrieval of string and numeric attributes.