Dimension Order in an MDX cube view as datasource

[lotsaram]

I got confirmation from IBM that the variable order matching the order of dims in the query is expected behavior and not necessarily the TABDIM order is expected behavior as of 2.0.9.10.

So in other words, they fixed it, then broke it again, and now they aren't going to fix it becasue it has been reclassified from a bug to expected behavior. And they expect us to use MDX views? Seriously?

[ascheevel]

I don't love it, but if it stays consistent I can work with it. I'm bothered by the need to remap variables on existing TIs with mdx views, but that's a one time effort. I'm bothered that IBM's fix documentation simply said it was fixed as of 2.0.9.10 without clarifying what the new expected behavior is. This suggests to me that they either didn't care or believed -quite incorrectly obviously as this thread stretches back to 2019- that nobody was using mdx views.

I guess I'm still in the camp of liking MDX views and will continue to use them when they make sense, but it's a hit to my pride when a solution of mine worked fine yesterday and fails today because of something as trivial as variable order.

[PavoGa]

Resurrection of an older thread.

Client has PAoC. Processes reading cube views with and MDX view (CreateViewByMDX) using one alternate hierarchy have been returning the dimensions in the order documented in my earlier post on the subject regarding TABDIM order with the alternate hierarchy usage exception.

This week, the TI stopped working. Why you ask? Because it is now returning the dimensions in the order they are called by the MDX, including the alternate hierarchy in its called position, not somewhere else.

Be interested if others have had this failure recently.

PS - it could have changed within the last couple of weeks, this process is loading budget/forecast numbers and is not run but once or twice a period.