А построение перекрестных ссылок опять сожрет всю память и завесит систему нафих

[sukhanchik]

Цитата:

Сообщение от alex55

Дополню, что также можно обновлять только ссылки определенного слоя, отфильтровав по utilLevel и поставив флажок "Выбрано" перед запуском - может быть полезно для получения актуального состояния для текущих разработок на верхнем слое, например usr. Соответственно время обновления и требования к памяти гораздо меньше, в соответствии с размером выбранного слоя/слоев.

Хе... А Вы так пробовали делать?
Вариант 1. Первый раз строим все ссылки, затем обновляем только по слою.
Эффект 1. Если мне не изменяет память (т.к. быстро отказался от этого варианта) - то не обновляются ссылки на использование объектов с других слоев. Т.е. если мы, к примеру в коде на usr-слое использовали InventTable, то перекрестные ссылки по InventTable об этом ничего не скажут.
Эффект 2. Будет задвоение (неоднократно видел собственными глазами). Т.е. в форме "Чем используется" каждая запись будет задвоена, затроена и т.д. для каждого построения ссылок.

Вариант 2. Ставим галочку "Удалить все". Но это удаляет ВСЕ записи - т.о. мы имеем ссылки только по usr-слою без sys и прочих слоев. Но в этом случае нет задвоения. Наблюдается ли эффект 1 - точно не помню - уж больно проверить все это временнозатратно.

На ноуте надо ограничивать память для SQL Server либо строить ссылки не на ноуте, а затем переливать таблички Xref*. Самый удобный на мой взгляд вариант - регулярный запуск на сервере построения ссылок ночью (ярлычок с axc-шником с параметром автозапуска compileAll_+). При этом еще для ускорения можно выполнить truncate для xRef*-таблиц до построения ссылок.
Плюс - уровень компилятора д.б. не больше 3 (а то и 2) - иначе может не хватить памяти для формирования лога