Page 2 of 2

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Mon Oct 10, 2011 11:42 pm
by mattgoff
Shoot, I had a long follow-up post written last week, but I guess I never submitted it.

After working with Karin (who must certainly also clothe needy children and organize neighborhood spay/neuter programs for pets, and never the reverse, in her spare time), I think I understand what happened in my case. I was already suspicious that the .pro file contains dimension ordering, which is redundant when you'll be guaranteed to have access to the .cub file. It turns out that dim ordering is also stored in the .vue file (along with a TON of other redundant info including displayed aliases for all elements in all dims in the view).

It's this redundant data that's the key. What I think happened in this case is that I was playing around with cube reordering around the same time I created the Default view for the cube (circa 2007). The new view picked up the reordered dims on the cube and stored them. At some point later, I got rid of cube reordering, but the vue still contained the reordering. This data corruption (my opinion) didn't really matter (and was never obvious) because this was an experimental cube that we never ended up using (but also never deleted).

Literally years later, I happened to use this view as the datasource. It's not actually used by the process-- it's just the cube with the largest number of dims so I used it to force the greatest number of variables in TI (I change it up with DatasourceCubeView in the Prolog which is set by a parameter sent by the parent process calling this child). The pro picked up the non-standard dim order from the vue and applied that reordering to the variables.

So:
  • Problem #1: Redundant data is being stored in different places and not updated in every location when it changes. This ties nicely back to my database normalization rant on another thread. In fact, this is probably the top reason for database normalization (not to mention efficiency).
  • Problem #2: Despite the fact that DatasourceCubeView alters the datasource, TI uses the dimension ordering from the original datasource (as stored in the pro, not what's currently in the cub) instead of getting it from the new datasource.
These are really both the same fix: store data in one place. If that's done, it's impossible for #1 to happen (since there is not a need to make multiple updates), same with #2 (since the vue/pro don't contain this data, it has to be a run time look at the cub).

Admittedly, this is a rare situation. But that's what best practices are all about: designing systems so that rare situations (which no one would anticipate and write a test case to verify) are covered. If this data was normalized, this problem would not have happened.

Frankly, I'm relieved that this is a file corruption issue, since it's a much easier fix than applying a HF to all nine of my servers. Plus, I got a little burned trying to go to 9.5.2 a few months ago, so I've frozen any updates until the budget is final. Should be a fun holiday season....

Matt

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Tue Oct 11, 2011 6:46 am
by lotsaram
This one really cheeses me off, especially since I reported in back in Feb 2009 with 9.4.1 but gave up in the face of the brick wall of support at the time. if you have a generic problem to ASCIIOutput any cube simply in V1, V2, V3, ... Vn, Value order and another generic process to load data in to cubes from flat file export then this can be a real problem if your system contains re-ordered cubes (and as a "best practice" cubes should be re-ordered so as to take up les memory and calculate user requests faster.)

Sure the ASCIIOutput may work fine if the definition of "fine" includes the data point address being in the re-ordered order not the TabDim order of the cube. But everything is not fine when the data is reimported and the importing TI errors on the CellPutN due to dimensions not being in the expected order.

I have seem several 0% helpful technote emails on this in the last few weeks all with meaningless "local fixes." Surely someone from engineering can agree that variables not being assigned to dimensions in original dimension order is a bug (that needs fixing) and not an enhancement.

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Tue Oct 11, 2011 7:37 am
by Steve Vincent
Agree 100%. My issue is i want to write TIs that create a view, use it, then destroy it. As all TIs have to use public views, i don't want the server (as now) to be festooned with hundreds of views only "admin" should see or use. In its current state, the TI creates a "corrupted" view as Matt has highlighted, hence my ticket and frustration at the continued delay in understanding the issue.

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Tue Oct 11, 2011 7:42 pm
by Martin Ryan
Seeing as IBM are reading, I'll add in my two cents that this is a pretty big issue which effectively renders the re-ordering function useless anywhere but in the development stage.

As it happens, about a week ago I was tempted to use the re-ordering function in a live system, rather than destroying the cube and rebuilding it. After seeing this post I obviously still can't do that. I'll have to stick with my 25% bloat.

The re-order function was introduced at least five years ago. Five years and it still doesn't work - that's up there with undo spread and subix.

Martin

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Wed Nov 16, 2011 4:53 am
by Gregor Koch
In case somebody is still interested in this. We had a PMR on this issue.
And...
Defect escalated for hotfix on 9.5.2 FP1.
The ETA for 9.5.2 FP1 HF2 is Dec 4

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Wed Nov 16, 2011 9:05 am
by Steve Vincent
Sorry been too busy to update this. My PMR was closed as they had agreed the defect and the fix for FP2 (maybe). There is a simple workaround tho so people do not have to wait for the fix & especially handy if you can't upgrade your software without a lot of hassle (like us).

Code: Select all

### FORCE CORRECT ORDER FOR DIMS IN VIEW TO AVOID BUG ###
ViewRowDimensionSet(Cube, SubName, Dim1, 1);
ViewRowDimensionSet(Cube, SubName, Dim2, 2);
ViewRowDimensionSet(Cube, SubName, Dim3, 3);
ViewRowDimensionSet(Cube, SubName, Dim4, 4);
ViewRowDimensionSet(Cube, SubName, Dim5, 5);
ViewRowDimensionSet(Cube, SubName, Dim6, 6);
ViewRowDimensionSet(Cube, SubName, Dim7, 7);
ViewRowDimensionSet(Cube, SubName, Dim8, 8);
ViewRowDimensionSet(Cube, SubName, Dim9, 9);
As long as those are in the order of the cube as it was built, the TI will work. Thanks to Karin at IBM for chasing that one to get a solution, originally they didn't agree it was a bug...

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Tue May 14, 2013 4:02 pm
by rturpyn
I know this thread is over a year old, but I'm trying to implement the suggested code above and having an issue dynamically determining the dimension order to set for the view. I would have thought TabDim was grabbing the correct dimension order from the cube, but it's not. Are you guys hard coding the dimension order for each cube when creating a view in TI?

Code: Select all

## Determine Dimension Order
sDim1 = TabDim( pCube, 1 );
sDim2 = TabDim( pCube, 2 );
sDim3 = TabDim( pCube, 3 );
sDim4 = TabDim( pCube, 4 );
sDim5 = TabDim( pCube, 5 );

## Reorder View
ViewRowDimensionSet(pCube, cTempViewFrom, sDim1, 1);
ViewRowDimensionSet(pCube, cTempViewFrom, sDim2, 2);
ViewRowDimensionSet(pCube, cTempViewFrom, sDim3, 3);
ViewRowDimensionSet(pCube, cTempViewFrom, sDim4, 4);
ViewRowDimensionSet(pCube, cTempViewFrom, sDim5, 5);

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Wed May 15, 2013 8:00 am
by Steve Vincent
No, your code is just the same as mine & i use it in most of my processes now. Tabdim always returns the correct dimension for the order, it was only the TI datasource preview that was jumbling it up. It suggests there is a different problem somewhere...

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Wed May 15, 2013 9:28 am
by lotsaram
rturpyn wrote:I know this thread is over a year old, but I'm trying to implement the suggested code above and having an issue dynamically determining the dimension order to set for the view. I would have thought TabDim was grabbing the correct dimension order from the cube, but it's not. Are you guys hard coding the dimension order for each cube when creating a view in TI?
I haven't ever seen TABDIM return anything other than the originally defined dimension order that is shown in the GUI. The bug discussed in this thread is for incorrect order assignment of variables in a TI process. If you really have TABDIM returning dimension names as per optimized dimension order and not original order then that would be a new bug (and a quite concerning one.)

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Wed May 15, 2013 12:09 pm
by Steve Vincent
Indeed it would. Forgot to check which version you are on, if this isn't working in 10.1.1 then i suggest you raise it with IBM as an urgent issue. My problem was a specific version of 9.5.2 and was hotfixed a while ago. I just can't upgrade our clients here to take advantage of the fix.

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Wed Jan 03, 2018 1:35 pm
by Mark RMBC
Apologies for resurrecting an old post but does anyone know if this issue was fixed for 10.1.1?

I have loads of processes that create and delete views on the fly and want to be certain that if I reorder any cubes it won't have a negative impact anywhere.

cheers, Mark

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Fri Jan 05, 2018 9:29 pm
by PavoGa
Apologies for resurrecting an old post but does anyone know if this issue was fixed for 10.1.1?

I have loads of processes that create and delete views on the fly and want to be certain that if I reorder any cubes it won't have a negative impact anywhere.

cheers, Mark
Mark, we are on 10.2.2, do the same thing in most of our processes, have re-ordered a couple of cubes and have not noticed this being a problem.

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Mon Jan 08, 2018 2:45 pm
by Mark RMBC
Hi PavoGa,

thanks for the response

cheers, Mark

Re: PMR68125 999 866: TM1 952 TI CubeView Incorrect Order

Posted: Thu Sep 13, 2018 11:31 am
by bgregs
Mark RMBC wrote: Wed Jan 03, 2018 1:35 pm Apologies for resurrecting an old post but does anyone know if this issue was fixed for 10.1.1?

I have loads of processes that create and delete views on the fly and want to be certain that if I reorder any cubes it won't have a negative impact anywhere.

cheers, Mark
Hi Mark,

Just to chime in, I was also concerned about reordering in production after reading this thread. I walked through Steve's example (creating my own TIs and cubes in PA 2.0 as per Steve's original example) and can confirm that this is no longer an issue. Looks like we can finally rest easy :D