Цитата:
Сообщение от
Raven Melancholic
Это просто мы терпеливые.
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser.
Цитата:
Сообщение от
michel1971
Вместо рестарта аоса, можно попробовать дернуть \Classes\ReleaseUpdateBulkCopyDB\flushNextRecIdForTable
Цитата:
Сообщение от
Logger
В общем, нашел более простое решение. Суть в том, чтобы не сдвигать RecId ПОСЛЕ массовой вставки данных, а в том, чтобы изначально "обнулять" RecId (ДО построения перекрёстных ссылок)
Т.е. общая схема такая:
- Перед началом построения перекрестных ссылок останавливаем АОС (это вообще всегда полезно - прочистить память). Предполагаем, что с CIL проблем нет (он не развален и актуален для процедуры обновления ссылок)
- Очищаем XREF*-таблички (через TRUNCATE)
- Сдвигаем RecId по ним в табличке SystemSequences на "нулевое" значение. В роли "нулевого" значения я взял значение, которое устанавливает АХ для свежесозданной таблицы
- Стартуем АОС и начинаем строить перекрестные ссылки
В моём случае (когда я использую отдельное приложение для сборки ссылок) на целевом приложении ссылки уже строились несколько раз и RecId уже сдвинуты на достаточно приличное "расстояние" от "нулевого".
Т.о. после массового переноса данных - в целевом приложении - в SystemSequences будут следующие значения RecId гораздо больше, нежели они будут сгенерированы на промежуточном приложении. Как следствие - проблем не возникнет.
Да, это конечно всё заморочки... Но сделав их один раз, запихнув в скрипт и шедулер уже про них забываешь и получаешь результат не думая, какими усилиями он получается.