TM1 Forum

I was trying to re order the dimensions in a cube and was getting the Erorr Re Ordering Dimensions on one of my cubes. It is my largest cube, but I should have plenty of space on the server. My current model in total is about 4 gig and the server has over 9 gig free so I do not suspect memory because there should be plenty of space to make a copy of the cube.

What else could it be that is causing the issues? I can re order all the other cubes fine. Is there anyway I could get additional details on the generic error? Not pertinent appears in the logs.

The only time I have seen this is if you try and move a dimension containing string values which is typically the last dimension.

Leave that alone and move the rest and you should be fine.

Tom

I guess the other possability is that the bit of code that checks to see if a reorder will exceed the RAM limits has not been updated for 64 bit?

The dim order is important, i had similar isues when i was trying to move a dim that had string values to a place it didn't like. If you have calculated what you think the best order is its definately worth looking at possible string values as i had to leave one dim where it was for that reason.

Thanks to everyone for all the help. It was the string in a dimension issue. The strange part is we reorged a few years ago and it allowed it to be changed then.

Thanks again.

Hmmmm....
I was in one of Joe Puztai's Best Practices sessions a few years ago and I do believe he made a flat statement appropos of having an extra measure dim in all cubes, where text could go, that it was fine because you could reorder later.
What version/bitness were you using? May need an SR.

It's always been that way - I don't think an upgrade will help. The elements from the last dimension in the cube determines what type of cell it is - string or numeric.

In the past you may have been able to re-order because, despite there being a string element, you didn't actually have any string text in the cube. However if there is string data and you try to reorder the string element's dimension further up the cube, then the cell that contains the string will no longer be a string cell and thus it won't allow you to reorder it.

Martin

Just tried it out on 9.0SP3U9 and yes, if there are string elements in the last dimension you can't resequence it. Time to drop Joe P a line, methinks, or to raise an SR.

I think it is a known error are you are SOL. Rebuild the cube.

Eric wrote:I think it is a known error.

I don't think it's an error. In a multi dimensional cube, there has to be something that dictates whether a cell is a numeric cell or a string cell. TM1 has always used the 'N' or 'S' element type of the final dimension to dictate whether it is a string or numeric intersection. If you move that dimension, then it will then use the elements in the new last dimension which will usually all be N elements, hence it will want to make the cell numeric, hence the error.

I guess there is the possiblity that TM1 will one day allow you to dictate which dimension is the measures dimension and use that dimension to control whether an intersection is a numeric or string value, regardless of the location of the dimension in the cube - but until that day, it'll be the last dimension and thus you won't be able to move it once you have string data in the cube.

Cheers,
Martin

Martin, I agree. But Joe Puztai, giving a Best Practices session, left me a pretty firm impression that you could do this. One of his BP mantras was 'always have an extra measure dimension, put it last, you can put text in but you can still resequence'. I've been applying that (and most other BP ideas) for a while, and don't want to made to look more of an old dodderer than I feel many mornings. So Joe.....

The whole strings in the last dim things has drifted in and out for a while. There was certainly a time when you were able to(or at leaset we were told you could) have strings in any positioned dimension, maybe late 7 early 8, not sure. It was a bit of functionality that never really stuck though.