Error Creating View Array

[Mark RMBC]

Hi,

I am experiencing some behaviour that I don’t understand and was hoping someone could throw some light on the issue.

I have some year-end processes that among other things update an Admin cube to reflect the new year and also a process that deletes an old version.

The problem is that after I run the process to delete the old version and then I try to open a view I get an error saying “Error Creating View Array” and the system crashes. If I restart the sever everything works fine again.

However if I open a view before I run the process to delete the old year version everything works ok and there are no errors or crashes?

The TI process code (all on Prolog) to delete the old version is:

Code: Select all

vYear = Cellgets('UH_Admin','Value','Previous Year Desc');
vVersion = vYear | ' Current Version';
DimensionElementDelete('UH_Versions', vVersion);

The above process is executed from a master process (on Epilog). Which looks as follows:

Code: Select all

executeprocess('01.05a Admin Control Update CYR Admin Cube');
executeprocess('01.05b Admin Control Delete Current Version');
executeprocess('01.05c Admin Control Create NYR Attr');

In the actual views the version uses a subset derived via some MDX code, as follows:

Code: Select all

{TM1FILTERBYPATTERN( {TM1SUBSETALL( [UH_Versions] )}, [UH_Admin].([UH_Time_Measure].[Value], [UH_Time_Date].[Current Year Desc]) +  " Current Version")}

It should be noted that even if I make the subset static the problem still persists?

cheers, Mark

[tomok]

The problem is that after I run the process to delete the old version and then I try to open a view I get an error saying “Error Creating View Array” and the system crashes

This is the error you get when you delete an element from a dimension and that element is part of the saved view you are trying to open,like one of the title dimensions or hard-coded in one of the rows or columns. If you are going to remove an old version from your "Versions" dimension they you also need to fix all the views that had the version in it.

FWIW, it still shouldn't cause a server crash but I've seen a million things in my career that shouldn't cause TM1 to crash, but still do.

[Mark RMBC]

Hi Tom and thanks for the reply,

The issue is that all the views use mdx code to retrieve the version, none are hard written (therefore I assume not in need of fixing), I posted the mdx in my first comment.

Do I need to do a save at the end of the process?

cheers, Mark

[tomok]

The issue is that all the views use mdx code to retrieve the version, none are hard written (therefore I assume not in need of fixing), I posted the mdx in my first comment.

So the subset is MDX, great. Does it resolve to another actual member in your Versions dimension AFTER you removed the version you are talking about? If not, then the view won't open. You cannot open ANY view that references ANY subset that is empty OR you have hard-coded elements in the title dimensions that are no longer in the dimension. Basically, a view has to include actual live elements from every dimension in the cube or you get the error you got. Any easy way to debug a view that won't open is to right-click on it and choose "Export as text data". Then you click on each of the dimensions and make sure they all reference active elements. Once you find the empty one that's your problem.

[Mark RMBC]

Hi Tom,

Appreciate your patience!

I am still doing tests but I can confirm the following so far:

For the Versions dimension the view references a subset which is derived via MDX (the mdx looks at a string value in the admin cube). This admin cube gets updated before the old version is deleted so the mdx will reference the new string value in the admin cube.

So I tested the process,

Before I ran the year end processes the version in the subset was “2017 to 2018 Current Version” and this was being used in the view.

After I ran the year end processes I checked the version dimension to make sure the subset was referencing the new version, i.e. “2018 to 2019 Current Version” and it was. So the mdx and the subset resolves to an actual member in the version dimension.

I then restored the backup and redid the test, did as you suggested and right clicked choose "Export as text data" and all dimensions returned the expected elements.

It should be noted that I was running the processes as a non admin user and when I ran the processes as an admin user I got no view array error, so I changed the process security against the non admin user group from read to write and reran the processes. There were no view array errors. I reran the process just to double check and no errors again. So it appeared that changing the process security from Read to Write solved this problem.

However after retesting this a few times with process security as write, on one of the occasions I got the array error, but only once out of 4 times. So am going to test a few more times to see what happens.

But to my mind, all very mysterious?

cheers, Mark

[Mark RMBC]

Further update:

Tested again with all process security as Write and the first year rollover worked with no errors
Rolled year over again and no erros
Rolled year over for third time and did "Export as text data" and got the following errors in sequence:

• The View Handle Copied in the Subset is invalid, then

• Parent Object of copied view is not a cube, then

• Error accessing information

edit: When I restarted the server and opened the view all was ok and the correct elements were retrieved

cheers, Mark

[gtonkin]

Do you have element security on the Version dimension? If so, do you do a security refresh?

[Mark RMBC]

Hi gtonkin,

there is no specific security, just everything defaults as Write for that group against the dimension elements.

When you say refresh security do you literally mean SecurityRefresh or ElementSecurityPut?

Also, an update on my testing, I reran the processes with process security as Write and got the error, so that appears to be a bit random.

If I don't delete the old version then the error never appears. So for some reason even though the subset is updating somewhere this isn't being recognised.

cheers, Mark

[gtonkin]

...
When you say refresh security do you literally mean SecurityRefresh or ElementSecurityPut?
...

I mean run a SecurityRefresh, as a test for now, to rule out that after adding a new element, there is not a permissions issue for non-admin users.

[Mark RMBC]

Hi gtonkin,

Adding SecurityRefresh to the final year end roll over process didn't solve the issue, still returned errir array.

I did another test of hashing out the delete old version part of the process and got no errors. This is why I am assuming the problem is one of TM1 not recognising the new version and for some reason still thinking the old version is in use?

cheers, Mark