Parent Unique Error in TM1 Executive Viewer

[tm1expert]

Hi Everybody,

Has anybody experienced an EV Error when using a TM1 Datasource? When users try to open an EV View, sometimes TV throws an error:
Failed to open database

Invalid Outline Definition

Parent Unique Name ‘xxx’ specified for member 'yyy' could not be found in the member chain.

According to IBM this error happens when metadata changes have happened to a Secured DImension. We get this error even if no metadata changes have happened to any of the secured dimensions, and this is driving me crazy. Any workaround I try to implement, does not work.

We are using EV 9.5 with TM1 9.5.2

I am 100% sure that there was no metadata changes into the secured dimensions, in fact, in any of the dimensions, but users are getting this error all the time during the day.

Is there any parameter in the EV Config File that would help?

Thank you
Ardian

[lotsaram]

Usually this is happens when EV has not pre-built the dimension outline and a user accesses a view but due to element security there are "breaks" in the chain of elements and EV is unable to build the full dimension outline. Immediate work around is to have a user with admin access open the view so EV can build the full outline then other users opening afterwards will not get the error. More permanent fix it to make sure that the "preload" option is checked for the cube database so that EV builds the full outline with the specified admin account when the EV service starts rather than waiting for the first user to access a view - this plus ensure the EV service is recycled following any dimension updates or security updates to the secured dimensions should fix it.

[tm1expert]

Hi Lotsaram,

The strange thing is that the error happens eventhough no metadata changes or security changes happen. We do not make any metadata changes during the day.
I have built a VBScript that runs the ForcePreload command for all the Cubes, and we run this after every metadata change that happens overnight. ANd users go in the the morning and they are fine, the problem happens later.

When the problem happens, we run the VBScript again and it clears the error, but this is still unaccepted from users, since in a busy day close their Plan Wave deadline, this issue stops them from doing their job.

Regarding the Preload Checkbox for Cube Databases in EV, this option is not selected, but on the datasource object on EV Server, for Preload Cubes option, we have selected "Always", and we were told that with this option you don't have to specify the Preload Option for each cube.

Do you think that we should change that?

I'm trying to post a screenshot here, but I don't know if it will work or not:)

Thank you

Force_Preload_Setting.gif (58.78 KiB) Viewed 3044 times

[lotsaram]

I'm no expert in EV, especially when it comes to running scripts to do a force preload, but it sounds like you have the immediate workaround to fix the issue already sorted.

I can't see that there is any harm having preload checked for each cube even if you have "always preload" already selected for the data source but if EV does what it says on the tin then this is probably unlikely to solve your issue. It really sounds like when EV checks the metadata timestamp it believes that the copy EV is holding from the preload is out of date based on the timestamp received from the data source. So are you really 100% certain that there has been no security change or metadata change affecting the dimension since the preload? (this might include changes to public subsets as well as dimension structure and possibly any security refresh operation not just DimensionElementSecurityPut).

Also, if the EV server is on a different machine that the TM1 server are the system clocks on each server in sync?