Когда то задавал здесь вопрос про то как сделать куб с выбором единиц измерения количественных данных.
Сильно никто не подсказал, но я додумался сам. Но оказывается - рано радовался.
А сделал я это следующим способом.
В таблицу измерения товарной иерархии, добавил поля для коэффициентов пересчёта единиц измерения. Получилось типа:

Таблица измерния "Товары":
Id int
Pid int
Name VarChar
Коробка numeric
Кг numeric
...
Поля "Коробка", "Кг" и как раз и хронят коэффициенты пересчёта, на которые делится количество из таблицы фактов.

Сделал отдельную таблицу со списком единиц измерния "Единицы":
Структура:

Id int
Name VarCahr

И заполнил её записями типа:

Коробка
Кг
...

По таблице фактов сделал куб "Продажи", который содержит только "физические" количественные поля.

По таблице "Единицы" сделал одноимённый куб, который содержал только одно одноймённое измерение по этой же таблице.

Потом всё это счастье объединил в виртуальный куб.
В итоге, имея из куба "Продажи" физические количественные меры и из куба "Единицы" измерение "Единицы" я смог организовать выбор едниц измерения.
Т.е. пользователь выбирает в измерение "Единицы" нужную единицу, а в вычисляемом поле "ФактКол" считается:

iif(
isleaf([Товары].CurrentMember),
[Measures].[ФКол]/ cdbl([Товары].CurrentMember.Properties([Единицы].CurrentMember.name)),
sum(descendants([Товары].CurrentMember,,Leaves),[ФактКол])
)

где
ФКол - физическое поле количество факта продаж.
ФактКол - вычисляемое поле количества факта продаж с учётом единицы измерения.

Всё было классно пока я не наткнулся на следующие проблемы:
1. Если измерени "Товары" находится в области фильтров то в некоторых случаях, в вычисляемое поле начинает выводиться какая то фигня типа
-9777Е-08
Именно что в некоторых случаях, так как общую закономерность я не уловил. Например фигня выводится когда в иерархии выбраны не все члены и в ветке выбраные не все но несколько членов.
Если же выбрать все члены измерения, или все члены одной ветки то всё ОК.
Опять же если выбрать целиком несколько веток находящихся на одном уровне - опять фигня. У меня конечно оригинальный метод определения коэффициента, но даже если написать cdbl([Товары].CurrentMember.Properties("Коробка")) , то это не помогает. Хотя я значения коэффициентов проставил даже для корней.

2. Если измерение "Товары" находится в таблице (область строк или столбцов) то невыбранные члены измерения "Товары" всё равно учитываются в итогах.
Можно конечно сказать что типа "а откуда сервак знает что вот по этому
[Товары].CurrentMember
в выражениии
sum(descendants([Товары].CurrentMember,,Leaves),[ФактКол])
не суммировать?"
Но почему же он тогда не суммирует когда иерархия находится в области фильтров?

Делал это поле в PivotTable, а не в самом кубе - результат тот же.

Подскажите пожалуйста в чём проблема?
Очень нужно!!!!!!!!

Мда....
Вообще для меня наиболее важен второй пункт, т.е. проблема суммирования в итогах не выбранных членов.
Я так понимаю проблема в том что для измерений помещённых в табличную часть, клиенту в результате запроса, передаются все члены, без учёта выбрано/не выбрано.
В результате суммируются все листья.
Может тогда есть какой нибудь другой способ формирования набора данных вместо descendants который можно подставить в sum?

Блин.....
Я этот sum(descendants использовал во всех кубах!!!!
А сдача проекта через несколько дней!!!!!!

VZL, скажите, в чём принципиальное ограничение?
Действительно клиент (PivotTable) выгребает все члены без учёта фильтра если измерение находится на осях таблица, а если в области фильтров то всё ОК?
А другие (не Microsoft) клиенты ведут себя так же?

Не, ну это маразм какой то! Получается что тогда вообще в кубе практически не имеет смысла создавать вычисляемые меры акромя типа мера 1- мера 2.
Потому что если значение меры нужно, например, помножить на коэффициент различный для разных членов измерений, то тогда никак не уйти от суммирования в корне подчинённых листьев. А это получается бессмысленно, если в клиенте вот такая ситуация.
Либо всё таки я что то не понимаю либо действительно полная.....

По первому пункту тоже чуть стало "проясняться".
Похоже когда измерение помещаешь в область фильтров то работа с
...CurrentMember.Properties невозможна, так как сполшняком идут глюки.

Народ, скажите хотя бы, всё таки, клиент передаёт серверу какую - нибудь информацию о наложенных фильтрах или выгребает всё сплошняком, а потом сам фильтрует?

По второму пункту нарыл следующее.
Проанализировал MDX запрос генерируемый Crystal Analysis 8.5, там эта возможность есть.Конечно PivotTable может генерировать его под другому, но всё же...
Для измерний в области фильтров, выделенные члены перечисляются в Where.
Выделенные члены в измерениях на осях таблиц в Where не заносятся а перечисляются в кортежах на осях таблицы.
Я так понимаю в этом то собака и порылась.
Но тогда в какой момент рассчитываются вычисляемые поля?
Можно ли как нибудь сделать что бы для них тоже суммирование производилось "правильно"?

Вот такая переписка с самим собой... :)

.... или может есть клиенты которые во where добавляют члены и из измерений расположенных на осях таблиц?