Защита от повреждения типа таблицы в Аксапте 2012 R3

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

Это просто мы терпеливые.
На самом деле часто после копирования перекрестных ссылок на некоторых действиях Акса кричит, что не может вставить запись в XRef... Например, при просмотре таблиц при помощи Table browser.

Цитата:

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

Вместо рестарта аоса, можно попробовать дернуть \Classes\ReleaseUpdateBulkCopyDB\flushNextRecIdForTable

Цитата:

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

Может из-за этого ?
Открыть в новом окне объект из кода

В общем, нашел более простое решение. Суть в том, чтобы не сдвигать RecId ПОСЛЕ массовой вставки данных, а в том, чтобы изначально "обнулять" RecId (ДО построения перекрёстных ссылок)

Т.е. общая схема такая:

• Перед началом построения перекрестных ссылок останавливаем АОС (это вообще всегда полезно - прочистить память). Предполагаем, что с CIL проблем нет (он не развален и актуален для процедуры обновления ссылок)
• Очищаем XREF*-таблички (через TRUNCATE)
• Сдвигаем RecId по ним в табличке SystemSequences на "нулевое" значение. В роли "нулевого" значения я взял значение, которое устанавливает АХ для свежесозданной таблицы
• Стартуем АОС и начинаем строить перекрестные ссылки

В моём случае (когда я использую отдельное приложение для сборки ссылок) на целевом приложении ссылки уже строились несколько раз и RecId уже сдвинуты на достаточно приличное "расстояние" от "нулевого".

Т.о. после массового переноса данных - в целевом приложении - в SystemSequences будут следующие значения RecId гораздо больше, нежели они будут сгенерированы на промежуточном приложении. Как следствие - проблем не возникнет.

Да, это конечно всё заморочки... Но сделав их один раз, запихнув в скрипт и шедулер уже про них забываешь и получаешь результат не думая, какими усилиями он получается.