|
03.09.2009, 22:15 | #1 |
Administrator
|
Цитата:
Сообщение от alex55
Дополню, что также можно обновлять только ссылки определенного слоя, отфильтровав по utilLevel и поставив флажок "Выбрано" перед запуском - может быть полезно для получения актуального состояния для текущих разработок на верхнем слое, например usr. Соответственно время обновления и требования к памяти гораздо меньше, в соответствии с размером выбранного слоя/слоев.
Вариант 1. Первый раз строим все ссылки, затем обновляем только по слою. Эффект 1. Если мне не изменяет память (т.к. быстро отказался от этого варианта) - то не обновляются ссылки на использование объектов с других слоев. Т.е. если мы, к примеру в коде на usr-слое использовали InventTable, то перекрестные ссылки по InventTable об этом ничего не скажут. Эффект 2. Будет задвоение (неоднократно видел собственными глазами). Т.е. в форме "Чем используется" каждая запись будет задвоена, затроена и т.д. для каждого построения ссылок. Вариант 2. Ставим галочку "Удалить все". Но это удаляет ВСЕ записи - т.о. мы имеем ссылки только по usr-слою без sys и прочих слоев. Но в этом случае нет задвоения. Наблюдается ли эффект 1 - точно не помню - уж больно проверить все это временнозатратно. На ноуте надо ограничивать память для SQL Server либо строить ссылки не на ноуте, а затем переливать таблички Xref*. Самый удобный на мой взгляд вариант - регулярный запуск на сервере построения ссылок ночью (ярлычок с axc-шником с параметром автозапуска compileAll_+). При этом еще для ускорения можно выполнить truncate для xRef*-таблиц до построения ссылок. Плюс - уровень компилятора д.б. не больше 3 (а то и 2) - иначе может не хватить памяти для формирования лога
__________________
Возможно сделать все. Вопрос времени |
|
04.09.2009, 16:58 | #2 |
MCTS
|
Цитата:
Сообщение от sukhanchik
Хе... А Вы так пробовали делать?
Вариант 1. Первый раз строим все ссылки, затем обновляем только по слою. Эффект 1. Если мне не изменяет память (т.к. быстро отказался от этого варианта) - то не обновляются ссылки на использование объектов с других слоев. Т.е. если мы, к примеру в коде на usr-слое использовали InventTable, то перекрестные ссылки по InventTable об этом ничего не скажут. Эффект 2. Будет задвоение (неоднократно видел собственными глазами). Т.е. в форме "Чем используется" каждая запись будет задвоена, затроена и т.д. для каждого построения ссылок. Вариант 2. Ставим галочку "Удалить все". Но это удаляет ВСЕ записи - т.о. мы имеем ссылки только по usr-слою без sys и прочих слоев. Но в этом случае нет задвоения. Наблюдается ли эффект 1 - точно не помню - уж больно проверить все это временнозатратно. ... Плюс - уровень компилятора д.б. не больше 3 (а то и 2) - иначе может не хватить памяти для формирования лога Проверил описанные эффекты на DAX 4.0 SP2: Вариант 1. Эффект 1: Не проявился. После обновления ссылка на InventTable появилась. Если я правильно понимаю, то при обновлении ссылок для объекта, мы получаем записи по всем объектам на которые он ссылается. Соответственно обновлять ссылки на объекты с нижележащих слоев, чтобы узнать какие объекты на них ссылаются, не нужно. Эффект 2. Задвоения пока не обнаружил, хотя поведение системы мне не очень понятно. На скриншоте показано изменение кол-ва записей в таблицах при последовательном обновлении ссылок на usr без изменения объектов. То есть после 7-ой итерации кол-во записей не меняется, а на промежуточных итерациях меняется по странному алгоритму. Кстати, а что за лог, связанный с уровнем диагностики компилятора? Мне казалось что при обновлении ПС вывод диагностики не производится.. |
|
Теги |
перекрестные ссылки, ax4.0 |
|
|