А почему вас важна форма Unique Name ? Согласно OLEDB for OLAP, unique name является всего навсего уникальным идентификатором и не имеет никакой структуры. Провайдер может вернуть GUID если захочет. Полагаться на конкретную форму unique name - это очень опасно, потому что они могут меняться.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

Ребята - я не понимаю в чем проблема. Практически единственный способ получить member unique name - это из MDSCHEMA_MEMBERS schema rowset. Там есть и имя иерархии, и имя уровня, и просто имя - зачем парсить unique name ?

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

backfireВо вторых, только начиная с ADOMD.NET в документации появилось в явном виде.
ADOMD.NET SDK (Member.UniqueName Property)
The UniqueName property returns the fully-qualified unique name of the Member. To get the member name of the Member, use the Name property.
Warning Because this value is provider specific and may change in the future, it should be used in whole, and not be parsed.

Это не совсем верно. Еще в самой первой версии OLEDB for OLAP которая вышла в 1997 году была следующая глава "Provider Implementation Considerations for Unique Names":

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledb/htm/olapprovider_implementation_for_unique_names.asp

Там в частности написано что провайдеры вольны строить unique names как им захочется.

backfireTo get the member key of a Member, use the UniqueName property.

Это серьезная ошибка в документации - большое спасибо что Вы ее заметили. Мы во время tech review это пропустили :( Я открою на это дело баг.

backfireВот в этом то и наши проблемы - как получать member key, не используя "фичи" и work around и гарантировать независимость от "provider specific and may change in the future".

На это я дам два ответа:

1. А зачем Вам нужно знать key ?
2. А вот в Юконе это будет можно :)

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

Мне кажется, что в этой дискуссии смешано несколько понятий. Я попытаюсь рассмотреть какая между ними разница.

1. Member Unique Name - это уникальный идентификатор мембера. Он гарантирован быть одним и тем же если в кубе не было structural changes. Т.е. неважно как получен этот самый member unique name - через OLEDB, XMLA, ADOMD, ADOMD.NET и т.д. - он будет один и тот же. Куб который переехал из AS2000 в Юкон тоже должен сохранить unique names. Иначе, как заметил backfire, будет проблема с persisted views. Форма unique name никому не гарантирована.

2. Member Qualified Name - это форма по которой можно найти мембер в измерении, но она не гарантирована быть уникальной. Т.е. мембер
Заказчик.Россия.Ленинград.ВасяПупкин, может быть а может и не быть уникальным. Аппликация которая пользуется qualified name, должна знать можно или нельзя его использовать. Иногда AS2K решает использовать member qualified name в качестве member unique name, когда он знает наверняка что тот будет уникален.

3. Member Name Qualified By Key - это форма когда мембер в измерении находится по его ключу а не по имени. Это как правило уникально (хотя и не обязано быть таковым). Даже если member unique name не построен по принципу hierarchy.level.&key - все равно если ключ уникален на уровне, то такая форма будет работать не хуже member unique name.

Я всегда рекоммендую разработчикам оставаться в рамках куба и пользоваться только member unique name, потому что только такой подход является 100% правильным и совместимым с будующими версиями. Единственное для чего в AS2K нужны keys - это для dimension writeback, все остальное можно сделать не выходя наружу.
Иногда разработчики решают по какой-либо причине использовать ключи напрямую (нету времени сделать правильно, оптимизация производительности и т.д.).

Итог: никто не должен угадывать или парсить unique names, AS2K найдет мемберов и по ключам (см. форму 3) если есть надобность.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights