TM1 Forum

Posted: **Tue Oct 30, 2018 11:59 am**

It seems another issue has popped up where the hierarchy functionality is long on promise and wee bit short on delivery.

I thought that ElementAttrInsert would generate an attribute that is managed/stored by hierarchy. For instance, say an attribute is created in dimname:hiername1 for Element X, I want the attribute value to be 1, but in dimname:hiername2, I want that value to be 2 for Element X. This functionality seems implied as the function ElementAttrPutN requires a specific hierarchy to be named for each call.

However, that does not seem to be the way it is. For example:

Code: Select all

dimOrg = 'Organization';
hier1 = '2018 East';
hier2 = '2019 East';

ElementAttrPutN(2, dimOrg, hier1, 'Alabama', 'TheRealValue');
ElementAttrPutN(106, dimOrg, hier2, 'Alabama', 'TheRealValue');

results in 106 being the value across both hierarchies. Is there some setting that causes that or is that the way it is supposed to be? Am I over the rainbow here with thinking that functionality is implied because I sure have not read anything explains how this is supposed to work either way.

Posted: **Tue Oct 30, 2018 12:06 pm**

When I was doing my detailed testing I'm pretty sure I got to the same place.

Attributes appear to be old style objects that can't be varied by hierarchy. It would appear that IBM just created all the hierarchy equivalent TI functions without considering if the objects they addressed would exist / work.
No idea what IBMs plan is here or why it is going wrong.

Obviously you can build your own cube as a workaround...

Posted: **Tue Oct 30, 2018 12:34 pm**

Steve Rowe wrote: ↑Tue Oct 30, 2018 12:06 pm Obviously you can build your own cube as a workaround...

And that is pretty much the conclusion we reached as well, although we may consider adding attributes in the form of hiername_TheRealValue. We can easily enough, I think, handle that construction instead propagating numerous cubes to manage attributes by hierarchy.

Thanks for confirming, Steve. I was hoping for some obscure setting in the config file or undocumented "feature" that got around this.

Posted: **Tue Oct 30, 2018 10:27 pm**

Hi

Just to confirm - I tried an experiment. I created an extra ByWD hierarchy on the model dimension in SDATA and built a hierarchy according to whether the description had 2WD, 4WD or something else. I then created an Attribute 'Wheels' using ElementAttrInsert, which requires a Hierarchy parameter. On the Data tab I set the value of the Wheels attribute using ElementAttrPutS( NumberToString( vWheels) , vDim , vWDHier ,vModel , 'Wheels' ) ;

However, the end result was that the }ElementAttributes_model cube got updated with both the Wheels Attribute and its values, so effectively ElementAttrInsert is no different to AttrInsert and ElementAttrPutS is no different to AttrPutS. In other words the additional Hierarchy parameter to these functions is completely ignored.

I looked at the underlying folder for model}hiers just in case something had been created there was wasn't showing up in Perspectives but nothing was.

If it helps you, the noddy process that I used to prove this is attached. It might be easier to send this across to IBM rather than anything based on your model, since they must already have the SDATA sample cubes.

Regards

Paul Simon

Posted: **Tue Nov 06, 2018 8:13 pm**

Just noticed I failed to say thank you. Much appreciated, Paul.

TM1 Forum

Hierarchies and element attributes

Hierarchies and element attributes

Re: Hierarchies and element attributes

Re: Hierarchies and element attributes

Re: Hierarchies and element attributes

Re: Hierarchies and element attributes