TM1 Forum

I wonder if anyone out there knows a way to easily set the change flag of a TM1 cube without actually changing data.

I have used the undocumented SwapAliasWithPrincipalName TI-function many times in the past and it always worked fine for me, as long as I force every cube with the respective dim to be rebuild and stored on the disk again before server shutdown.
Knowing this I used to loop through every cube including the }-versions with this dim and put in a dummy value, removed it again and finally hit the save data button.
But this time it is a really large number of cubes, so that I can either write a TI to do this or someone tells me the missing piece of the SwapAliasWithPrincipalName, another undocumented way to set the flag on one or all cubes.

Oh, I just see PM65881 which tells this has been fixed with 10.1.1 and 9.5.2 FP3, let's see...

Why are you bothering? If the cube hasn't changed there is no need to update it.

This is or at least was the way to get the swap function to work. Have a look at other chats here where people were talking about data losses when using it.
In my mental model TM1 needed to recreate the cube files to map old data to new names internally, otherwise the data appear correct, but just until next server refresh.

David Usherwood wrote:Why are you bothering? If the cube hasn't changed there is no need to update it.

The reason to force re-saving the cube is important if you want to remove the alias from dimension after performing swap. If you don't re-save, the non-updated .cub file will have values assigned to old codes that cannot be recognized in dimension anymore.

What you could think of is a combination of wrapper and doer processes.
1. Wrapper has a parameter of dimension name (to provide dimension, where you performed your swap) and its source could be the }Cubes dimension.
2. In wrapper's Data tab you can check with TabDim if particular cube has this dimension and if yes, you call a doer process.
3. Doer process has as a parameter the cube name (provided from wrapper) and as a source a cube view.
4. In doer's Prolog tab you create full view for parameter provided cube with all skips set to 1 (so no consolidations, no rules, no zeroes). Then you set created view as the source. Finally you also set FirstRowProcessedFlag variable to 0.
5. In doer's Data tab you have a check, if FirstRowProcessedFlag equals 0.
5a. If yes, perform CellPutN operation. In here I am not sure, if taking CellGetN value from cell and putting the same value will cause cube to have "updated" status, or if you need to first put CellGetN +1 and then CellGetN value back again. After that also change FirstRowProcessedFlag variable to 1.
5b. If not, execute ProcessBreak which will go directly to Epilog.

Above is not tested, but I think it should work.
Will take some time to write it, but once you do it, you have a nice tool to use for all the rest of the cases.

If particular cube will not have any records to process (e.g. fully rule driven or just empty) then the doer will not do anything, but that should not be a problem - in such a case your .cub file should be values empty anyway, so you do not lose any numbers because of the swap.

HTH

Edit: And one more thing I forgot about while writing. You will also need to handle cases, when the updated cell would store strings instead of values (attribute, security and other cubes).