Я конечно, не могу с полной уверенностью судить что это именно баг, но я повторял это на двух разных компах с совершенно одинаковым результатом.
Итак, имеем MS AS 2000, sp3a. Источник данных MS SQL 2000.
Делаю куб. В нем - таблица фактов, измерения Товар, Склад, Дата. (Все - Shared)
По схеме "Звезда", все примитивно. Измерение Дата (Иерархия Год-Месяц-День) строится по вьюхе, состоящей из одного столбца формата datetime. Куб процессится и работает, все хорошо.
============ Приступаем к созданию "бага" ============
В измерение Дата на уровень День добавляем Member Properties - Неделя, которое выглядит так: .
Пока тоже все нормально. Делаю по этому полю виртуальное измерение "Неделя" (не важно Shared ил нет я делал и так и так) и добавляю его в куб. После этого куб не процессится, и самое неприятное OLAP-сервер пишет в журнал "Unexpected fatal error occurred. Attempting to restart server." и постоянно перестартует службу. Если успеть между этими рестартами (а это сложно) удалить этот куб (ЦЕЛИКОМ!), и удалить member properеies "Неделя", и удалить измерение "Неделя", то это не помогает. Сервис все равно стартует, грузит измерения в память (это прям видно) и после этого выгружается. SqlDumper создает дампы в каталоге Data но из них я что-то ниче не понял :-).
И я ничего лучшего не смог придумать, как грохнуть все базы и восстановить бэкап...
=================== Заключение ===================
Что я не так делаю? Это баг или кривые руки? Самое интересное, что по этому измерению Дата у меня уже созданы и работают виртуальные измерения Месяц и ДеньНедели !!! Мне все-таки кажется, что это баг....
Может выслать кому-нибудь файлик sqldmpr0021.mdmp? :-)

======

Спасибо что дочитали!

Да, я знаю, что это у многих было, топики эти читал, спасибо, и как поднять сервер знаю, это не проблема. Проблема в том, что делаешь вроде вполне обычные, документированные, правильные действия с совершенно неправильным результатом. А в данном случае я даже смог добиться эффекта стабильного повторения!
Кстати на одной машине у меня репозиторий был мигрирован на скул, а на втором - остался в mdb. Так что от этого не зависит...

А фиксить то я думаю никто особо не будет, потому что 2005-й, могучий и красивый на подходе :-))