Indexes - more info required

[mweldon]

Hi

I am trying to understand a problem with some elements moving oddly, and for that I have a few questions regarding indexes.

If I move an element to a different point in the hierarchy, will the index change? What if the element becomes listed twice in the hierarchy? We are running 9.1.4, we restart TM1 every night - does the index reset/change after a reboot?

The background - I am seeing some data disappear on an element after it moves in the hierarchy - which suggests to me that the element is being deleted somewhere then being recreated as a new element later on. (there are 156 processes [!] in the overnight chore, so I don't think its worth posting all the code!! If I can confirm this behaviour then I can go digging in the code.)

thanks for your help

-Marc

[Wim Gielis]

Hi Marc

If I move an element to a different point in the hierarchy, will the index change?

Yes, that's true. It is very often not a good idea to rely on indexes. Why and where do you need them?

we restart TM1 every night

Is there really a need to do this? You flush the memory of TM1 and thereby you do not take much advantage of storing calculated results in memory.

there are 156 processes [!] in the overnight chore

Hmmm. Why are there so many processes / so many different (!) data sources? Were these processes and the logic thoroughly reviewed?

In that many processes, I bet there are a lot of metadata changes and also zero out views, hence signalling out the issue with losing data will not be obvious (let alone the 150+ processes).

Can you provide more details perhaps?

Wim

[mweldon]

thanks for responding Wim. Lots of overnight processes is obviously far from ideal but thats how it is, the system works and I dont have the time to redesign it! (I didn't build the system). And yes, there are several processes that interact with this dimension so I'm not looking for specific help with sorting that out, but more with the general concepts of Indexes to allow me to understand what could be going on.

It seems the index of the element in question has indeed changed after an overnight run.

cheers

[Wim Gielis]

Hello

Rather than reviewing all the processes, do you see particular cases where the indexes are used - and where you see or suspect problems?

Might be easier to work on this in the short term.

WIm

[mweldon]

If an element was listed under an 'invalid codes' parent, then it got added to another part of the hierarchy (i.e. now listed twice in the hierarchy), then the element got removed from the 'invalid codes' parent - would you expect the index to have changed at all from what it was at the start? (after an overnight reboot as well)

thanks

[Wim Gielis]

would you expect the index to have changed at all from what it was at the start? (after an overnight reboot as well)

thanks

Chances are very big it does, yes.

Again, where do you/another developer use indexes? Is it in rules where you rely on "DIMNM(dim,DIMIX(dim,elem)-1)" kind of structures?

[Steve Rowe]

Hi,
Just to clear up a possible misunderstanding.
An element only has one index and this gives it's position when you hit the retrieve all / upside down A button.
If an element is added to another consolidation this won't in itself change the index number.

If the element index is changing overnight then it's likely that the dimension is being rebuilt, if the element is being deleted and added back in the same process then you should be OK data wise, if it is in different processes then you are doomed!

In general don't use indexes for anything ever, except for Dimix / Dimnm lookups.

DimensionDeleteAllElements is the devil work when it comes to dimension maintenance, again don't use it.

Good luck with your 156 TIs, did you get to see the system before you took the job on!

Cheers,

Steve

[mweldon]

thanks for your comments Steve. Indexes aren't used in the dimension build processes, I was just trying to use them for my own benefit to debug what was going on with certain elements.

thanks for clearing it up