You can use the same methods, just that you need to specify the attribute hierarchy instead of a user-defined one. Each attribute has its own hierarchy. In the Customer dimension in Adventure Works we have:

[Customer].[Country]
[Customer].[StateProvince]
[Customer].[City]

To get the All member in those you can use the same MDX statements as above:

[Customer].[Country].[(All)].Item(0)
or
[Customer].[Country].Levels(0).Item(0)

Same holds true for the other hierarchies.

This Helps clarify All Member Properties. Thanks for your the Post , it is very informative

Is there a way to address the All Member Properties or All Members for the intermediate levesl of hierarchies?

In above example intermediate levels will be Country, StateProvince ,City

Thanks once again

Regards

Dave

I wrote about it with the intention to show a potential problem with using the All member key. There is not too much literature around about the All member in general and I am quite satisfied with the result – Gerhard showed a simple method of referencing All member (even though it may result in some unexpected results if the dimension is non-aggregatable) and now we have a better understanding of the All member key.

I wish it was all a bit better documented in BOL.

Thanks to both of you (Darren and Gerhard) for your insights! :)

Returning null may have been a "less wrong" option, but I'm not sure if that is an option. I think that if the key of the underlying attribute is an int, it is internally mapped as C/C# int which is not nullable. But I have not played with this too much myself, I prefer to use non-null keys to avoid these sort of issues.

Also, wouldn't it be better if SSAS returns null on the All member to show that there is no key? Of course, using the key is not a good idea in most cases anyway, but assigning 0 could be confusing in my opinion.

I usually use [Customer].[Customer Geography].levels(0).item(0)

this worked for all my need so far and is independet of any name or key

greets,
gerhard