в MDX нельзя на оси склеить, структуру менять надо, оси элементами атрибутов определяют контекст для ячеек - в которые передаются значения т.е. на пересечении координат осей (за искл. всех остальных которые default по умолчанию)
хочешь на оси поставить значения? - не получится (можно только добавить дополнительные Properties, но систему координат не выкинешь)
так что создавай новые мемберы (элементы атрибута) или в ручную или меняй структуру
тогда один ключ на ось - а на него по 1:1 иерархии child как значение (пересечением с осью на которой выбранные элементы измерения расчётных мер, т.е. {событие,мера1} где мера.событие = ключ.parent..member_name)
на ключ можешь имя соотв. пациента повесить

можно с DMX поизвращаться (в том-же подключении/окне что и MDX), там и аналог SQL join можно завернуть (через SHAPE/APPEND)
в крайнем случае передавай MDX результат в SQL через openquery/openrowset, и там манипулируй(чисти, склеивай стринги, join-ь результаты) как нужно.

StarikNavy ,
да нет, openquery/openrowset (т.е. sql) сразу в тот-же день после вопроса через пару часов предложил, так что по ходу явно не прокатит из-за особенностей их локально-внутренних интерфейсов.

Гулин Федор ,
ещё раз предложу (natural prediction) join из DMX использовать, там вполне реально целые цепи разных результатов создавать, глянь как твой gui проглотит и отобразит такой запрос (соответственно Data Mining модель должна существовать в базе, создай какую-то минимальную для образца):

abcAccessories - CY 20122147.08106Bikes - CY 20125839695.32523269Clothing - CY 2012642.7922Accessories - CY 2013668241.5334409Bikes - CY 201315359502.369706Clothing - CY 2013323806.458686так-же можно через shape/append/relate join-ить результаты разных MDX запросов, напр.:
[Date].[Calendar Year].[Calendar Year].[MEMBER_CAPTION][Customer].[Country].&[Australia][Customer].[Country].&[Canada]x.[Date].[Calendar Year].[Calendar Year].[MEMBER_CAPTION]x.[Product].[Category].&[1]x.[Product].[Category].&[3]CY 20122128407.4551307604.5237CY 20125839695.3252642.79CY 20134339443.381085632.65CY 201315359502.36323806.45

П.С. сама идея от Chris Webb здесь (он это решал при помощи Allan Mitchell)
может получится не только горизонтатльно - но и вертикально сложить через UNION (т.к. DMX как наследник урезаного SQL его тоже поддерживает), но это уже на любителя поизвращаться если кому охота эксперементировать с туманными перспективами.
кстати - DMV вроде как основан на DMX

до SQL напрямую тебе насколько понимаю из MDX не получится достучаться, из-за этого ограничения:Гулин Федорвсе д.б в mdx - ибо его можно передать (скормить) гуи-клиенту1) но в окне MDX та-же выполняется и DMX который понимает openquery/openrowset (для первого нужен соответствующий DS, для второго - проверить настройки сервере/разрешить провайдера)
это на уровне SSAS
2) такая-же функциональность как указал StarikNavy есть и на уровне SQL (хотя тоже нужна дополнительная конфигурация от безопасности и ad-hoc distributed query, {linked server, openquery или openrowset}) - тогда можно манипулировать полями (колоннами) в SQL, но тебе это не подходит из-за ограничения

можно сделать напрямую на DMX (в MDX окне) или объединить первое и второе (из DMX вызвать SQL который выполнит MDX запрос и отформатирует результат) - но это наверное уже изврат какой-то (два раза вызывать openquery/openrowset, один раз как DMX и второй как SQL)

поэтому в свете ограничения - первичная задача проверить экспериментальным путём : работает-ли твой GUI с DMX.

Гулин Федорт.е это идея в том чтобы просто сделать запрос к исходной БД ( вместо mdx ) ?не совсем, используется функциональность SQL (для манипуляции с полями) - а сами данные берутся из SSAS
но до SQL не обязательно стучаться, проверь как DMX напрямую сработает, тогда DMX вытащит нужные поля из MDX

если не ошибаюсь - обычно чтобы разрешить openquery/openrowset на стороне SQL требутеся конфигурация типа
да, путь конечно муторный - но при такой задаче нужны альтернативы, хотя ещё раз - первый пример DMX из MDX даёт нужный результат без openquery/openrowset (на стороне SSAS), т.е. доп конфигурация не нужна. может ты путаешь с
? (я SQL сервер перед каждым SSAS процессингом в этот режим перевожу кроме XMLA конфигурации)

от куда делается однозначный вывод о доступе к исходным данным как цели последовательности операций? создаётся только подключение чтобы использовать более удобный инструментарий другого языка/диалекта (хотя при желании и можно получать из исходных данных - т.к. соединение в своём спектре имеет и такую функциональность)

Yuri Abele..Вопрос еще раз - а зачем нужно так замороченно, если можно просто взять два значения и склеить (при необходимости, конвертнув в строку)?Yuri Abele,
это одна из наиболее вероятных интерпретаций из вводной, т.е. особенностей GUI берущего:
(а) первую колонну из dataset
(б) на первую позицию
(в) при том что MDX возвращает в (a) - первую позицию вертикальной оси (set элементов атрибута)
(г) интерфейс работает с MDX и не работает с SQL

задача: вывести в условиях (а) и (б) несуществующий показатель в пределах ограничений (в) и (г)
что означает сужение альтернатив решений до:
0) (из-) менять интерфейс / или разбираться с его документацией-настройками (может и работает на самом-то деле)
1) {расчётную} меру (склеенную из стрингов) туда не получится поставить, значит можно только атрибут (если делать средствами MDX) - которого в нынешней структуре куба/измерений нет (т.е. надо делать/менять структуру)
или
2) не меняя структуру - использовать дополнительные возможности смежного/другого диалекта (взаимозаменяемость DMX и MDX) имеющую необходимую для решения проблемы функциональность.


как-бы никто и не спорит что можно склеить нужную меру, затруднение в том что такой вариант не вписывается в ограничения - следовательно не решает вопрос.



это о методологии основной проблемы,Гулин Федорпричем если 2 включены и там и там
Exception of type 'System.OutOfMemoryException' was thrown.
декарт похожевторая - часто обсуждаемая на форуме (out of memory или сходная/кореллирующая: ограничение в 4.3 миллиарда туплов в crossjoin) решается через nonempty/exists/auto-exists (если это не проблема на клиенте - Excel часто выдаёт данные лучше {быстрее и без переполнения буфера} чем SSMS) - для нужной группы мер (+использовав autoexists для атрибутов из одного и того-же измерения, особенно эффективно если связи между атрибутами настроены правильно)

причём NON_EMPTY_BEHAVIOR и NonEmptyCrossJoin - уже практически списанная функциональность (последние SSAS ядра это уже оптимизируют внутри автоматом)
для решения вторичной проблемы можно ещё рассмотреть последовательность в которой выполняются запросы MDX: from(subcube-subquery)/where(slicers)/with(sets-members)/axis/having&non empty

ну тогда я наверное неверно понял вот эти вводные: 20388517 Гулин Федор..ps там проблема в том что на дашбоарде в том гуи-клиенте можно показать толкьо 1 столбец-категорию (мер можно сколько угодно.)
(разработчики говорят что будет больше - но когда не известно).. 20388611 Гулин Федор..СПС за быстрый фидбек
еще раз - там именно Calculated меры
А мне надо склеить атрибуты разных димешененов в 1 поле
чтобы обойти проблему в GUI клиенте
(мер там можно показать сколкьо угодно - а вот столбец Categories один)..