Elisanc issues in TI (951)

[Jeroen Eynikel]

Hi,

I am having a strange issue with a TI process and the elisanc function in TM1 951.

Basically the situation is this.

I am updating a dimension with multiple unbalanced hierarchies.
One type of update needing to happen is that an element of whatever level may change to a different parent.

So I started by setting up attributes for every hierarchy that contain the current parent. (I am updating from a file that only contains the new structure).

My idea was to simple do a dimensioncomponentelementdelete using the element and its respective parent (by referring to the contents of the attribute) and then to do a componentadd based on the file.

In itself this worked OK, but an annoying side effect was that I got a lot of errors as the same line may appear multiple times in the source file leading to errors when it is trying to remove the element from a parent that it was already removed from.

So I figured I would add an intermediate check using elisanc / eliscomp. The problem however seems to be that the TI for some reason always seems to return a zero on this check in everything but the first hierarchy.

It is pretty weird. I have let the TI do a an asciioutput of what exactly it is checking

(statement like:

ASCIIOUTPUT('C:temp\test_nettoyageH4.txt',vDim,CodeSite, pHierarchie4,ATTRS (vDim, codesite, pHierarchie4), 'PARENT ' | STR(ELISANC(vDim, ATTRS (vDim,codesite, pHierarchie4),codesite),1,0)); )

and the result of these checks is always zero. Nevertheless when I fysically look at the dimension the element does still have 'ATTRS (vDim,codesite,pHierarchie4) as a parent. If I test the elisanc function by entering it as a variable, the variable does return a 1. But for some reason it does not have the same result when actually processing the file.

I have limited the file to a single record in order to be sure there is no issue with the data itself, but I still get the problem.

So f.i. starting situation

- Element1 is a child of Conso1 in Hierarchy2. It also has a text attribute specifying conso1 as its parent.
- In the file it now states element1 needs to be a child of conso2

If I do the check ELISANC(vDim, 'Conso1',element1) by creating a variable it returns 1.
If however I run the process the check ELISANC(vDim, ATTRS (vDim,codesite, pHierarchie4),codesite) (which is the exact same check - just dynamic) the process returns a zero.

This leads to the end result that the child is not deleted from conso1, but is inserted under conso2 as well leading to double counting.

I am not manipulating the dimension or value of the attribute during this process other than componentadd / delete statements.

I can probably circumvent the problem by removing the elisanc check and checking on a(nother yet to be created) attribute in which I track whether the element has been deleted already from its parent or by updating the attribute as soon as the componentdelete has occured once but I really want to know why the elisanc is not working.

Anyone have any thoughts on this?

Jeroen

[ajain86]

prior to do doing the elisanc check, have you tried to retrieve and store the attrs value in a variable?

[Jeroen Eynikel]

Yes. The attr values are what they should be.

Anyways I have worked around the problem by getting rid of the elisanc and consistently updating the attribute but I am still clueless as to why it didn't work with the elisanc...

[Steve Vincent]

if you are building elements in to a dimension, don't forget that the changes are only commited once the TI has finished. you can't check for something on the value you just added in the previous line of your datasource, and that is probably why the elisanc is coming up zero.

[Jeroen Eynikel]

if you are building elements in to a dimension, don't forget that the changes are only commited once the TI has finished. you can't check for something on the value you just added in the previous line of your datasource, and that is probably why the elisanc is coming up zero.

Hi Steve,

I am aware of that and I specifically wrote the process taking this into account. As said I am NOT adding anything to the dimension. I may change the existing parent of an existing element to another pre-existing parent, but I am never introducing anything new.

I figured that inspite of that the elisanc may return a zero in case the parent 'just changed', but the check happens before actually changing the parent and on top of that it works fine for the first hierarchy, just not for any of the others even with only a single record in the file (so no possibility at all the thing moved to another parent in some way) - hence why I don't understand the result and think it must be some sort of bug.

But as said I have worked around the problem so I am not going to lose any more sleep over it...

[cycleman83]

Another possible solution would be... In the prolog, spin through the entire dimension removing all elements that are not N-Level. This will remove your hierarchy, but not compromise any of your data.

Then, in the metadata tab, you can rebuild your hierarchy, which is sourced from the file.

This eliminates the need for those extra attributes that you are creating and using.

[Jeroen Eynikel]

Hi Cycleman,

unfortunately that is not an option in this case.

The problem is that I have taken over the project from some other consultants who really made a lot of errors, a.o. all of their dimensions were created with base elements including the label - not taking into account labels can change. I would very much prefer to completely recreate the dimensions in a proper way but the client can not be convinced of that. (and the workload involved would be very considerable)

Also the files I am getting do not necessarily include all elements again. I.e. I can not delete anything, even not aggregated levels as the file may not contain the information necessary to rebuild the hierarchy for everything.

So I am basically forced to write some very creative TI code in order to try to resolve the issues in a reasonable way but I can not ever delete anything....

Jeroen

[William Bockstaele]

Please have a look to the TI under atatch, this could help you.
Looks more or less the same issue we have, it could give you some ideas.