У Вас работает правильно, а я вообще низвесно что тестирую :-(

Как я выяснил, на MSDN, под видом декабрьского CTP в начале декабря лежал совсем не декабрьский :-(.

А я так старательно на нем тестировал :-(



Кстати я выяснил еще одно странное поведение. Упоминание неизвестного члена, не выдает ошибку, а считает как ни в чем не бывало. Неужели это "by design"?

Например это запрос, отрабатывает, как будто where вообще в нем не присутствует.

MoshaЧто касается Aggregate - то попробуйте Ваш set с DistinctCount measure - никакого double counting быть не должно. Для других measures, в CTP build включен старый алгоритм, как я уже писал в другом thread, пока ломать backward compatibility ради производительности не дают, поэтому новый код который убирает дупликаты не включен.

Я знаю, что с DistinctCount все OK. А вот для нормальных мер, это еще вопрос, что считать правильным. Как вы уже заметили ранне, правильнее было бы исключать на уровне MDX-Engine, двойной учет, а не корячится на уровне прикладного MDX.

MoshaВообще-то это новая фича, но уже куча народа жалуется :) Мы хотели как в SQL - если в WHERE condition набрал неправильное имя - то не ошибку, а игнорировать, т.е. WHERE City='NoSuchCity' в SQL это не ошибка. Ну мы сделали новое свойство измерения - MdxMissingMemberMode - его можно посмотреть в dimension properties, которое говорит поднимать ошибку или нет. По умолчанию не поднимать. Сейчас у меня DCR на основе жалоб от людей которым это не понравилось - например внутри MDX Script - всегда будет ошибка, плюс connection string property для контроля. А Вы что по этому поводу думаете ?


Я думаю что с SQL можно было бы сравнивать выражение типа

Customer.CurrentMember.UniqueName = "NoSuchSity",

а в MDX Customer.NoSuchCity есть объект (базы данных), а не строка.
И обращение к свойствам несуществующих объектов должно давать NullReferenceException, (в SQL упоминание несуществующих столбцов тоже дает ошибку)

Кстати, в AS2005 есть еще один, как мне кажется, баг.
Если кого то угораздит обозвать Calculated Member именем существующего физического элемента, то в AS2K мы получим ошибку с четким изложением причины, а в AS2005 выдастся результат для существующего физического члена.

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