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

[Андре]

Цитата:

Построение перекрестных ссылок лучше не делать на сервере.
Построение перекрестных ссылок лучше не делать в период, когда нагрузка близка к максимальной.

Построение перекрестных ссылок дучше делать частями, а не всем скопом сразу. Например, сначала классы, потом таблицы, потом формы и т.д. В этом случае, меньше вероятность, что системе не хватит оперативной памяти и начнется работа со свопом.

[mazzy]

Цитата:

Сообщение от Андре

Построение перекрестных ссылок дучше делать частями, а не всем скопом сразу. Например, сначала классы, потом таблицы, потом формы и т.д. В этом случае, меньше вероятность, что системе не хватит оперативной памяти и начнется работа со свопом.

На самом деле, пользоваться этим советом стоит с осторожностью.
Особенно новичкам.

Утечку памяти, похоже, победили. Тьфу-тьфу-тьфу.
Посмотрим, что будет в 4.0.1, на которой будет основана русская версия.

[alex55]

Цитата:

Сообщение от Андре

Построение перекрестных ссылок дучше делать частями, а не всем скопом сразу. Например, сначала классы, потом таблицы, потом формы и т.д. В этом случае, меньше вероятность, что системе не хватит оперативной памяти и начнется работа со свопом.

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

[sukhanchik]

Цитата:

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

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

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

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

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

[alex55]

Цитата:

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

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

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

Пробовал, но пока еще изучаю на предмет подводных камней.

Проверил описанные эффекты на DAX 4.0 SP2:
Вариант 1.
Эффект 1: Не проявился. После обновления ссылка на InventTable появилась. Если я правильно понимаю, то при обновлении ссылок для объекта, мы получаем записи по всем объектам на которые он ссылается. Соответственно обновлять ссылки на объекты с нижележащих слоев, чтобы узнать какие объекты на них ссылаются, не нужно.

Эффект 2. Задвоения пока не обнаружил, хотя поведение системы мне не очень понятно. На скриншоте показано изменение кол-ва записей в таблицах при последовательном обновлении ссылок на usr без изменения объектов. То есть после 7-ой итерации кол-во записей не меняется, а на промежуточных итерациях меняется по странному алгоритму.

Кстати, а что за лог, связанный с уровнем диагностики компилятора? Мне казалось что при обновлении ПС вывод диагностики не производится..