TM1 Forum

Running into a problem with entering data into a consolidation for a spread.

1. Same VM server.
2. Two separate instances
3. cfg files both include: ProportionSpreadToZeroCells=T and the failing instance has been bounced twice to make sure this is in effect.
4. The capability assignments are identical in the two instances

However, one allows the entry of data into a consolidation, the other does not.

Has anyone run into this and is there some other setting besides the cfg setting mentioned above and capabilities to allow this kind of entry? I have not been able to find anything.

Is the security setup equal ?

Wim Gielis wrote: ↑Wed Jan 30, 2019 1:27 am Is the security setup equal ?

Yes,none of the objects involved here (dims, cubes, etc) have any security applied as yet in either instance. Plus, I'm an admin.

Additionally, PAX is not allowing entry into the consolidation either.

What happens if you use the right click spreading options do you get any kind of error message? These should be the same bits of functionality accessed I different ways.

Tried that as well and got the same error, Steve. Just flat out will not allow it. Changed method to do what needed to be done without entry at a consolidation, but at some point we are going to want to do user input at a consolidation and have it spread. I feel it has to be some setting and if/when we determine the cause, I'll post it.

Maybe spreading capability is explicitly denied?
https://www-01.ibm.com/support/docview. ... wg27043557

Found the problem and just wanted to provide an update.

In the ORG dimension, the leaf element the spread was being applied to did not exist in the Leaves hierarchy, just the ORG:ORG one. No problem with that, just add the element to the Leaves hierarchy and it spreads just fine.

Except while correcting this we found another problem. Could not add the missing element to Leaves because the element, in the ORG:ORG hierarchy, had an alias that was identical to the principal element name. So, for example, in ORG:ORG the element ORG.00001 had an alias of ORG.00001 and did not exist in Leaves. Removed the alias and we were able to add ORG.00001 to Leaves. Included this just in case someone runs across that issue as well.

Thanks to bgregs for chasing this down.

Whew!

Can you remember the creation sequence that led to this? In theory every N level should end up in the leaves hierarchy, if this is not reliable then this is a bit of an issue..

Steve Rowe wrote: ↑Thu Jan 31, 2019 9:53 pm Can you remember the creation sequence that led to this? In theory every N level should end up in the leaves hierarchy, if this is not reliable then this is a bit of an issue..

Absolutely agreed!

I have also seen this happen. The behaviour of the Leaves hierarchy should be “maintenance free” for addition of elements. That is if a leaf element is added to the same named hierarchy or any alternate hierarchy it will automatically appear in the Leaves hierarchy. I have found this to be mostly true but sometimes the Leaves hierarchy gets "out of sync" and doesn’t contain all the leaf elements from the other hierarchies. When this happens any additional new N elements added to other hierarchies get added to Leaves and elements deleted from Leaves are removed from other hierarchies. But the out of sync elements remain out of sync. The Leaves hierarchy being out of sync also survives a server restart.

This has me really scratching my head as there doesn't seem to be any "sync leaves hierarchy" function, either in TI or Rest API. So when it happens (which has been a handful of times = a handful of times TOO MANY) the only solution is to run a TI that loops over all hierarchies and checks for existence of all leaf elements in Leaves and if Dimix=0 add the element.

Wondering who else has seen this and if anyone has heard from IBM on the issue?

lotsaram wrote: ↑Thu Jan 31, 2019 10:03 pm

Steve Rowe wrote: ↑Thu Jan 31, 2019 9:53 pm Can you remember the creation sequence that led to this? In theory every N level should end up in the leaves hierarchy, if this is not reliable then this is a bit of an issue..

Absolutely agreed!

...

This has me really scratching my head as there doesn't seem to be any "sync leaves hierarchy" function, either in TI or Rest API. So when it happens (which has been a handful of times = a handful of times TOO MANY) the only solution is to run a TI that loops over all hierarchies and checks for existence of all leaf elements in Leaves and if Dimix=0 add the element.

Wondering who else has seen this and if anyone has heard from IBM on the issue?

We have several TIs written to manage the alternate hierarchies for these "features." So far:

1) VZO not working if targeted leaf elements do not exist in dimname:dinname. Syncs Leaves to dimname:dimname.
2) Syncs leaf elements in alternate hierarchies to Leaves.

If interested, could share some code if I can get permission from the client.

Steve Rowe wrote: ↑Thu Jan 31, 2019 9:53 pm Can you remember the creation sequence that led to this? In theory every N level should end up in the leaves hierarchy, if this is not reliable then this is a bit of an issue..

Not exactly, no. But the most common that I know of is cold migrations. A server startup does not fix anything.