Caret (^) in MDX

[MarenC]

Hi,

In PAW I have noticed the MDX includes a Caret. This seems to represent parent and child.

The issue is that this then throws up all sorts of member not found errors in the logs.

Has anyone noticed this before? I presume we just have to live with it?

Maren

[lotsaram]

This is for the member unique name (MUN) as there is a distinction in TM1 between elements and members. Any element which has multiple parents within a hierarchy will be represented by as many unique members as it has parents. What the carets represent is the path to the element by traversing the ancestors, depending where you drill down from.

Anyway that's what is means when you see something like [Product].[Product].[Total by Size^XL^aa321x] when maybe you were expecing just [Product].[Product].[aa321x] (which as far as querying the data goes should return the same result). But you shouldn't get member not found errors. Unless the MUN is saved in the PAW definition of the report and in the meantime the structure of the hierarchy has changed and the original rollup path from when the book was created now no longer exists.

[MarenC]

Thanks for the reply.

Looking at the dimension, the element is no longer a child of the parent.

So the dimension hierarchy has changed but the PAW mdx doesn't reflect this.

So when you say

Unless the MUN is saved in the PAW definition

As opposed to what? Or another way of putting it, how do you avoid this?

Maren

[lotsaram]

Thanks for the reply.

Looking at the dimension, the element is no longer a child of the parent.

So the dimension hierarchy has changed but the PAW mdx doesn't reflect this.

So when you say

Unless the MUN is saved in the PAW definition

As opposed to what? Or another way of putting it, how do you avoid this?

Maren

Now that is a good question!
I would raise this as a bug with IBM (but they will probably tell you this is "by design"). Ideally the report definition should just store the element references and generate the MUN reference on the fly, but it doesn't seem it has been done this way. The only way to avoid this is to be careful deleting /renaming rollups in your dimensions.

Also note: this only happens where you have multiple parents within a hierarchy. If elements have only a single parent then the MUN doesn't contain the drilldown path fro the root ancestor but is just the element reference. If you separate independent rollups into separate hierarchies then this issue can't bite you. (Of course it isn't actually practical to maintain all dimensions like this).