Page 1 of 1

TM1 9.4 Breaking Change - Rule derived Aliases

Posted: Mon May 04, 2009 6:05 am
by Jordan
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.

Re: TM1 9.4 Breaking Change - Rule derived Aliases

Posted: Mon May 04, 2009 8:06 am
by lotsaram
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.
(You missed the S: qualifier in your post of the rule.)

I just tested this myself on 9.4 MR1, 9.4 FP1 and 9.1.4 and replicated this exactly as you describe (zip attached - unicode).

I have gotten out of the habit I previously had of creating "code & description" aliases this way and now as a rule (pardon the pun), load all aliases via TI for performance reasons.

This must have slipped through the cracks in testing, interesting that it has taken this long to notice this bug.

Re: TM1 9.4 Breaking Change - Rule derived Aliases

Posted: Tue May 05, 2009 4:04 pm
by Steve Vincent
Hi Jordan,

Thanks for highlighting the issue - can i ask have you logged this with Cognos? If so it would help if the post followed the "Bugs Reporting" guide located at http://forums.olapforums.com/viewtopic.php?f=18&t=251 . As their current system doesn't allow you to track anything but your own issues, it helps by collating them here so we don't all try and log the same thing.

Welcome to the forum btw :)

Re: TM1 9.4 Breaking Change - Rule derived Aliases

Posted: Fri May 08, 2009 3:46 am
by Jordan
@ Steve Vincent

Thanks for the welcome.

I read the reporting guide prior to posting - not sure if I've followed it appropriately or not.

I have not logged this issue with Cognos/IBM. Other developers that I've spoken to recommended starting with this forum. I'm happy to help with any additional info.

Re: TM1 9.4 Breaking Change - Rule derived Aliases

Posted: Fri May 08, 2009 4:19 am
by Alan Kirk
Jordan wrote:@ Steve Vincent

Thanks for the welcome.

I read the reporting guide prior to posting - not sure if I've followed it appropriately or not.

I have not logged this issue with Cognos/IBM. Other developers that I've spoken to recommended starting with this forum. I'm happy to help with any additional info.
It was a good post; well detailed and illustrated. I think Steve just meant that if you had an Insight issue number it's always good to include it in the subject line (as per most of the posts in this sub-forum) so that everyone knows that it's already logged, and won't log it themselves if they come across it.

However, that having been said... reporting anything is a bit problematic at the moment. (See http://www.tm1forum.com/viewtopic.php?f=3&t=979) If you decide to hold off until the IBM system comes on line, then posting details of the IBM S/R reference would be useful.

Re: TM1 9.4 Breaking Change - Rule derived Aliases

Posted: Thu Nov 27, 2014 2:32 pm
by gtonkin
Just a quick update on this one for those on 10.2.20000.50183 (not FP1)

This issue has re-surface but appears to have been corrected in 10.2.2 FP1 (10.2.20100.123)

I cannot find any mention of the fix in the Fix List but aftert the number of issues on 10.2.2 would encourage everyone to update to FP1 and avoid hours of frustration. New undocumented features await you :lol: