setting dimension security within TI?

[kbogies]

Hi!

i have a chore that contains several 'rebuild dimension' processes, which 1 was encountering sporatic errors. Occationally, the TI process wasn't fully destroying the dimension prior to (re)creating it, all within the 1 'rebuild' process. i opened a PMR with IBM (haha) and haven't been able to fix this issue. However, i've been using a workaround by creating 2 seperate processes; 1 to destroy the dimension and 1 to create the dimension (again). however, now the problem is that the created dimension's secutiry defaults to none.

1. has anyone encountered this same error within a 'recreate' dimension process, and if so, were you able to find a solution? e.g. taking the script from generated statement and typing in below. i'd like to hear a success story before doing this because like i said, it fails sporatically and therefore i'm not sure i'd ever really be able to sign off on this solution.

2. does anyone know how to set a dimension's security within a ti process? it's not mentioned within the documentation, just user or element security.

thanks!

[George Regateiro]

As for the setting of dimension security you can just use a regular CELLPUTS referencing the }DimensionSecurity (I think that is it) cube.

[paulsimon]

Hi

I suspect the reason for your problem is that the dimension is part of a cube and therefore cannot be destroyed.

Instead I would try using DimensionDeleteAllElements in the Prolog, and then rebuilding the dimension in the MetaData tab of the same process.

As the dimension is never destroyed you won't lose security.

If there is some reason why you can't do this then George's suggestion of putting the READ access value in to the }DimensionSecurity cube will work, but you will probably need a Loop to do it as it will need to go in for each Group that uses the Dimension. You would also probably need to do it in the Epilog to be sure that the dimension has been created first.

Personally I find Destroying dimensions, or even DimensionDeleteAllElements a little risky because of the problems that you can get if something goes wrong in the rebuilding part of the process.

The process I use is to do a DimensionDeleteAllElements on a Temp copy of the dimension, eg Product_Temp, and rebuild the Temp dimension. Then I use another process to remove all consolidation links from the real dimension, eg Product. I then use another TI to copy in the structure from the temp dimension. There is then a final process that sweeps up any elements that are left with no parents and links them to an Orphans consolidation that feeds up in to the All Products element.

It might sound quite involved, but in practise, I call all of this from a Master Process that calls the different steps of the rebuild in a loop for each of the hierarchical dimensions in the system, which I just list in a subset. That means that all the dimensions get handled in the same uniform way, which makes them easier for the end-user to understand as well.

The advantages of this approach are:

1) As no elements are deleted, only consolidation links
a) You cannot accidentally lose data during a rebuild.
b) You cannot lose element security settings
2) The temp dimension means that, during testing, you can test out the results of any rebuild before affecting the master dimension.
3) In the final dimension all elements are guranteed to consolidate in to the top level All Products element, so there is no risk of missing some numbers.
4) Elements without a proper parent are easy to find by looking at the Orphans consolidation. You can then investigate why the elements have not been assigned a parent in the rebuild process.
5) If something goes wrong in the dimension rebuild, eg you create a circular reference, then the failure will happen on the Temp dim and the main dimension will not be affected.
6) You can apply variations to this process according to whether the dimension can be completely rebuilt from a source system, or whether the dimension hierarchy is manually maintained and perhaps just the base level elements come from the source system.

Regards


Paul Simon

[kbogies]

I suspect the reason for your problem is that the dimension is part of a cube and therefore cannot be destroyed.

actually this is the only dimension that is not used in a cube. it is a reference cube so some of the advanced users can see the relationships between one of the other dimensions with a level of another dimension (the parent level of the later does not have a direct relationship to the first dimension, which is why i didn't make 1 dimension out of the two). this model is heavily used by folks who need relational data, so this is a work around for sure... not to get into it, but active forms, i hope, will solve their issues.

Instead I would try using DimensionDeleteAllElements in the Prolog, and then rebuilding the dimension in the MetaData tab of the same process.

actually, the rebuild dimension processes generate DimensionDeleteAllElements in the Prolog, so i misspoke earlier when i said the process wasn't able to fully destroy the dimension, rather, it was not deleting all elements.

Personally I find Destroying dimensions, or even DimensionDeleteAllElements a little risky because of the problems that you can get if something goes wrong in the rebuilding part of the process.

under average circumstances, i agree; however this model is entirely rebuild every week based on the ever-changing relationships in the database. so every week, the chore runs through a number of zero out, rebuild dimension, and load data processes, so the intention is to clear the model out every week.

thank you for your responses, i will give the CELLPUTS a go now

[kbogies]

success with CellPutS! Thanks, there's so many functions that i'd never know or think to use until the situation presents itself, so i appreciate all suggestions:-)