При перенаправлении OLAP куба на другую базу пропадают данные

[DTD]

Добрый день

Возможно то сталкивался с похожей проблемой или имеет большой опыт работы с кубами.

Был стандартный AX2009 набор кубов привязанный к рабочей базе. Все работало замечательно.

Через Restore сделали дубликат этой AS базы. Расширили куб Ledger Transactions путем добавления пары полей в LedgerTrans Named Query через LEFT OUTER JOIN.

Теперь ситуация такая что на тестовой базе куб отлично работает, возвращая расширенный Ledger Trans, при перенаправлении на рабочую базу пересчитывается без ошибок, явно проходит через все миллионы Ledger Trans но в итоге данных по LedgerTrans нет (пустые ledger trans amount, count measures) хотя по Ledger Budget из того же куба все в порядке.

При пересчете куба выбираю всю базу, включая связанные объекты, потом делаю Refresh.

Зашел в тупик где смотреть, RLS же на кубы не распространяется, что еще может быть разного между базами ? Просил супер-админа пересчитать под своим логином - результат тот же.

[dmitro]

После редиректа на нужную базу deploy и process делаете? После этого в DataSourceView в таблице LedgerTrans есть записи через ExploreData?

[DTD]

Что подразумевается под Deploy ? Process.. конечно делаю, пробовал эксперементировать с разными режимами - паралельно / одна транзакция / с зависимыми обьектами и без.

В Explore Data записи есть (5000 там вроде только выбирает), если копирую из Named Query sql v SQL Manager и запускаю на нужную базу, возвращает все что я ожидаю увидеть, но в кубе Measures все равно пустые (

[Vadik]

Что мешает создать в BIDS проект на основе рабочей базы и после build-а задеплоить визардом на тестовый сервер?

[DTD]

Да сейчас после многочисленных пересчетов уже не работает и там где работало:

При пересчете честно проходит через миллионы записей Ledger Trans
После пересчета записи есть в Explore Data
Выдает записи если запустить SQL напрямую на базе

Простейшая Measure Ledger Trans Count выдает ноль(Measures в модификации вообще не касались, стандатные аксаптовские)

Еще заметил одну вешь - когда в кубе идешь на вкладку Partitions, там для Ledger Trans партишн практически пустая - 960 байт, на стандартном кубе где-то 320GB

[DTD]

В общем, в кратце, - у баз были рассинхронизированны ID enums из CUS слоя. Ну и в добавок неопределенности с пересчетным процессом. Хорошо что получилось определить проблемные enums, иначе их там десятки в стандартных кубах что при такой ситуации в тяжело модифицированной системе чревато ..