lotsaram wrote:kangkc wrote:Must say it's a terrible mistake. You probably realized by now by changing the element back to N doesn't get back you data. Hence by restarting and revert the dimension changes will not help either.
... not necessarily ....
If a save data had been done with the old dimension structure and the dimension then changed to convert N to C then this doesn't re-write the .cub and .feeders files. If the server was brought down (with no action in-between to cause a data change to any affected cubes) and the .dim file replaced with the old one then the server brought back up then this would in theory restore the data. I have seen this work before. (also in a backwards and unintended fashion where dimension elements were deleted as a shortcut to deleting data as cubes were very large and so zeroouts took too long, after elements were re-inserted and the server restarted data reappeared in cubes where there had been no data change and update of the .cub file)
So restore from this scenario *can* be quite simple and quick but it depends very much how soon the error is realized and action taken. Recovery fro something like this is never without risk.
Well..I remember having this working as what you have described in 9.x world.
Before replying fleaster I did a test on 10.2.2 to make sure.
But on 10.2.2 I am not seeing the same behaviour. I did a change from N to C, and from C back to N, all N data was wiped out.
No save data, data input, restart in between. It's a simple element property change.
I went on further testing by using rule to override the N element with dummy data. As soon as rule statement is removed, I get back my original N level entered data. Similar mistake but different results.
Confusing enough but this is what I am seeing in 10.2.2.
That's why I suggested to change from C back to N to see if fleaster managed to get back the data, else restore cub seems to be the only way out.
