Переполнение recid - это не ошибка, а закономерное последствие импорта данных.
Если у тебя при импорте не стоит галочка Comress RecIds, то система вытаскивает из файла с импортом данных минимальный и максимальный recid таблицы в исходной БД и резервирует в новой БД numRecIdsToReserve=MaxOldRecId-MinOldRecId. Скажем, у тебя есть две копии БД. Боевая БД,с vendTable.recid от 1 до 2000 и реальным числом записей в 1800 (200штук в разное время удалили). Ты эту базу копируешь на полигон, как-то там правишь данные в vendTable, потом эскпортируешь данные в файл и из файла импортируешь в боевую БД. В боевой БД при импорте, будет зарезервировано (2000-1)=1999 записей и счетчик recId в systemSequences перескочит с 2001 на 4000. При этом новые recId импортируемых записей будут рассчитываться как OldRecId+2001.
Делается это для того, чтобы убыстрить импорт. В том случае если в том же файле экспорта найдутся данные другие таблиц, ссылающиеся на ventTable.recId, то эти ссылочные поля будут автоматически пересчитаны по тому же алгоритму.
Если галочку compresss RecIds включить, то система будет вести во временных таблицах (со всеми вытекающими последствиями) карту соответствия старых и новых recId и в конце импорта запускать процедуру sysImport.recIdSimpleUpdate(), которая замещает все ссылки по recId на новые значения recId. Это отнимает много времени.
Если же ты будешь регулярно повторять трюк с копированием БД на полигон, а затем перекидкой данных из полигона на рабочую БД с помощью стандартного экспорта/импорта без сжатия RecId, то каждая такая операция будет приводить к удвоению максимального recId в таблице, и спустя 53 подобных операции, 64 разряда переполнятся.
То есть - переход на 64битные recId в новых версиях аксапты, позволил решить проблему только исчерпания recId для часто обновляющихся таблиц (таких как reqTrans или recTransCov, в общем таблиц из которых часто удаляют и заново вставляют данные). Проблему импорта этот переход не решил, а только слегка снизил (ровно на 32 импорта
)