Рассмотрим сложную техническую ситуацию, с которой сталкиваются администраторы и разработчики 1С при выполнении процедуры «Тестирование и исправление» (ТиИ). Ошибка «Ошибка при попытке вставки записи с не уникальным значением ссылки», указывающая на временную таблицу _tmpRCT, является критической. В случае использования СУБД (SQL) процесс прерывается сообщением об ошибке, а в файловом варианте база данных может просто закрываться с системным дампом. Особенно часто эта проблема проявляется в распределенных информационных базах (РИБ) на уровне подчиненных узлов.
Для начала проанализируем, что представляет собой таблица _tmpRCT. Эта таблица не является постоянной частью структуры данных 1С. Она создается платформой динамически непосредственно в процессе выполнения ТиИ, а именно на этапе проверки ссылочной целостности. Платформа использует её для промежуточного хранения идентификаторов объектов, которые имеют «битые» ссылки или требуют пересчета. Если при заполнении этой таблицы система пытается вставить один и тот же внутренний идентификатор (ID) дважды, возникает конфликт уникальности, и процесс останавливается.
Выясним причину, почему это происходит. Основной фактор — коллизия метаданных. Это ситуация, когда в системных таблицах конфигурации (таких как Config или DBSchema) два разных объекта метаданных (например, два справочника или документ и перечисление) ошибочно получили одинаковый внутренний числовой код. В центральном узле РИБ такая проблема может отсутствовать, но при некорректной синхронизации или сбое реструктуризации в периферийной базе данные «перемешиваются».
Если ваша база данных работает под управлением MS SQL Server или PostgreSQL, мы можем провести глубокий анализ. Как отметил автор темы, поиск по конкретному значению ID (например, 0x00000054) позволяет увидеть конфликтные записи. Рассмотрим, как найти дубликаты объектов в структуре метаданных.
Для поиска объектов с одинаковыми идентификаторами в SQL можно использовать запросы к системным таблицам. Посмотрим на пример логики поиска (учтите, что в новых версиях платформы DBSchema хранится в бинарном виде, поэтому первичный анализ часто проводится по косвенным признакам в таблице Config):
-- Пример запроса для поиска дублей в структуре (условный синтаксис)
SELECT TabID, COUNT(*)
FROM [_tmpRCT]
GROUP BY TabID
HAVING COUNT(*) > 1;
Если запрос возвращает значения, значит, система действительно пытается обработать один и тот же объект метаданных несколько раз. Проанализируем ситуацию: если вы нашли два разных объекта метаданных с одним ID, это означает глубокое повреждение конфигурации подчиненного узла.
Важно обратить внимание на используемую платформу. В рассматриваемом примере фигурирует версия 8.3.12.1790. Разберем этот момент подробнее. В ветках 8.3.12 и некоторых релизах 8.3.13 существовали специфические ошибки в механизме SDBL (уровень абстракции СУБД), которые приводили к неверной реструктуризации таблиц при обновлении конфигурации. Платформа могла «забыть» удалить старые описания таблиц или неверно назначить ID новым объектам.
Рекомендация: Первым делом попробуем обновить технологическую платформу до актуального стабильного релиза (например, веток 8.3.20 или выше). Часто более современные версии платформы при запуске ТиИ или простом обновлении конфигурации умеют более корректно обрабатывать и исправлять хеш-суммы метаданных.
Поскольку проблема специфична для подчиненного узла, рассмотрим способы восстановления синхронизации метаданных:
.cf) из центрального узла. В подчиненном узле перейдите в «Конфигурация — Загрузить конфигурацию из файла». Это принудительно перезапишет таблицы Config и DBSchema, что может устранить дублирование ID._tmpRCT вручную перед запуском ТиИ, хотя, как показывает практика, платформа пересоздает её заново. Использование команды TRUNCATE TABLE _tmpRCT может помочь, если ошибка вызвана «мусором» от предыдущих неудачных запусков.Tool1CD для анализа таблицы DBSchema. Если там обнаружены дублирующиеся строки с именами таблиц или их ID, их придется удалять или править вручную, что требует предельной осторожности.Проанализируем ситуацию: если в базе найдены два разных объекта с одним ID (как в сообщении 9), и простые методы (обновление платформы, загрузка .cf) не помогают, наиболее надежным способом будет создание нового начального образа подчиненного узла.
Разберем по шагам, почему это эффективно:
Иногда ошибка может быть связана не с объектами метаданных, а с записями в планах обмена. Посмотрим на таблицу Params. В ней могут зависать записи о незавершенных операциях обновления или реструктуризации. Проанализируем наличие записей типа db-check-needed или v8users. Если вы уверены в своих силах и имеете бэкап, очистка содержимого таблицы _tmpRCT перед повторным запуском ТиИ в режиме SQL может дать платформе шанс завершить проверку успешно.
Важное резюме: Ошибка в _tmpRCT — это всегда следствие нарушения логической целостности самой структуры базы данных. Не пытайтесь просто «удалить мешающую запись». Ищите причину в несоответствии метаданных (конфликт ID) или в багах старых версий платформы 1С.