Как исправить ошибку «Ошибка при попытке вставки записи с неуникальным значением ссылки» при обновлении метаданных в Конвертации данных 2.1?

← На главную

При активной разработке правил обмена в конфигурации «Конвертация данных 2.1» (КД) специалисты часто сталкиваются с необходимостью актуализации структуры метаданных источника или приемника. Однако стандартный процесс обновления через режим «Модифицировать существующую конфигурацию» нередко прерывается системной ошибкой платформы 1С:Предприятие.

Типичный текст ошибки выглядит следующим образом:

{Обработка.ЗагрузкаСтруктурыМетаданных.МодульОбъекта(499)}: Ошибка при вызове метода контекста (Записать) Объект.Записать; по причине: Ошибка при попытке вставки записи с неуникальным значением ссылки. таблица Reference16.

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

Почему возникает ошибка неуникальной ссылки?

Для того чтобы понять природу ошибки, заглянем «под капот» информационной базы КД. База КД хранит структуру метаданных ваших конфигураций в виде обычных элементов справочников. Таблицы с именами вида Reference15, Reference16 или Reference7 в СУБД соответствуют конкретным справочникам КД (например, «Конвертации», «Объекты метаданных», «Свойства» или «Значения»).

Когда мы выбираем режим «Модифицировать существующую конфигурацию», обработка ЗагрузкаСтруктурыМетаданных.epf пытается сопоставить загружаемые объекты с уже имеющимися в базе. В этот момент может произойти конфликт уникальных идентификаторов (GUID/UUID):

Дублирование GUID в файле выгрузки: Обработка выгрузки структуры (например, MD83Exp.epf) из-за внутренних ошибок платформы или наличия расширений может дважды записать один и тот же объект с одинаковым уникальным идентификатором в XML-файл.
Конфликт версий в КД: В базе КД уже существует элемент с таким же GUID, но относящийся к другому родителю или конфигурации. Попытка записать новый элемент с тем же идентификатором блокируется СУБД для обеспечения целостности данных.
Ошибки кэширования метаданных: При частых выгрузках-загрузках кэш метаданных платформы может вести себя некорректно, передавая старые ссылки.

Рассмотрим подробнее пошаговые сценарии преодоления этой системной коллизии.

Способ 1. Обновление обработок выгрузки и загрузки метаданных

Первым делом проанализируем инструменты, которые мы используем для переноса структуры. Зачастую разработчики используют устаревшие версии внешних обработок выгрузки метаданных, оставшиеся от предыдущих релизов КД.

Выполним следующие шаги:

Перейдем в каталог шаблонов установленной конфигурации «Конвертация данных» (обычно это путь вида C:\Users\<ИмяПользователя>\AppData\Roaming\1C\1cv8\tmplts\1c\Conversion\<ВерсияРелиза>\).
Найдем актуальные версии обработок: MD83Exp.epf (для платформ 8.3) и встроенную обработку загрузки структуры в самой КД.
При выгрузке структуры метаданных из информационной базы источника или приемника с помощью MD83Exp.epf попробуем снять некритичные флаги. Например, если в правилах обмена не используются регистры сведений, регистры накопления или движения документов, снимем соответствующие флажки в форме настройки выгрузки. Это существенно уменьшит объем XML-файла и снизит вероятность коллизии дублирующихся GUID.

Способ 2. Загрузка структуры как новой конфигурации

Если нам необходимо срочно продолжить работу над правилами и нет времени на детальный аудит базы данных, воспользуемся самым быстрым обходным путем — загрузкой структуры в режиме создания новой конфигурации.

Разберем этот процесс по шагам:

Откроем обработку загрузки структуры метаданных в КД.
Укажем путь к файлу выгрузки структуры.
В поле выбора режима загрузки укажем «Создать новую конфигурацию» вместо «Модифицировать существующую». В этом случае КД создаст чистую структуру конфигурации с новыми внутренними ссылками.
Перейдем в настройки нашей конвертации (правил обмена) и заменим старую конфигурацию на только что загруженную новую.
После успешной перепривязки правил старую неактуальную конфигурацию в КД можно пометить на удаление и удалить через стандартную обработку «Удаление помеченных объектов».

Способ 3. Пересоздание окружения (Метод «Выгрузка правил -> Чистая база»)

Этот метод по праву считается самым надежным и «чистым», так как он полностью избавляет базу КД от накопившегося «мусора» и скрытых дублей ссылок в системных таблицах справочников.

Проанализируем алгоритм совместных действий:

В нашей текущей рабочей базе КД откроем правила обмена и выполним полную выгрузку правил в XML-файл. На этом шаге сохраняются все наши алгоритмы, обработчики событий, сопоставления полей и настройки конвертации свойств.
Создадим абсолютно новую пустую базу КД (можно развернуть ее из чистого шаблона КД той же версии).
В созданную чистую базу КД загрузим файлы структуры метаданных для источника и приемника. Загрузка пройдет без ошибок, так как таблицы базы абсолютно пусты и конфликты GUID физически не могут возникнуть.
Запустим операцию загрузки правил обмена из сохраненного на первом шаге XML-файла. При импорте КД определит, что конфигурации в правилах и в базе имеют разные идентификаторы, и предложит сопоставить их. Мы аккуратно указываем только что импортированные чистые конфигурации.
Сохраняем правила. Теперь у нас есть полностью рабочая, чистая база КД с обновленными метаданными без намека на ошибки неуникальных записей.

Способ 4. Особенности работы с уникальными идентификаторами (GUID) конфигураций

Выясним важную техническую деталь, связанную с тем, как КД идентифицирует загружаемые конфигурации. При выгрузке структуры метаданных обработкой в XML-файл записывается уникальный идентификатор самой конфигурации.

Если мы попытаемся загрузить один и тот же файл выгрузки несколько раз в качестве новой конфигурации, КД все равно будет сопоставлять ее с одной и той же записью базы данных. Это происходит потому, что КД ищет конфигурацию по внутреннему GUID, прописанному в начале XML-файла.

Например, в начале файла структуры мы можем увидеть следующий блок:


<?xml version="1.0" encoding="UTF-8"?>
<ДанныеФайла ВерсияФормата="2.0" ИмяФайла="V8Exchan.xml" ...>
<Конфигурация Идентификатор="a4b3d122-835c-4d2b-98df-89bca1128df2" Имя="БухгалтерияПредприятия" ...>

Если нам необходимо загрузить несколько идентичных конфигураций (например, для настройки обмена между тремя разными базами «1С:Бухгалтерия»), нам нужно либо делать выгрузку структуры из каждой базы отдельно (тогда платформой будут сгенерированы разные идентификаторы), либо перед импортом вручную изменить символ в параметре Идентификатор внутри XML-файла структуры метаданных.

Способ 5. Поиск дубликата на уровне СУБД (Для продвинутых администраторов)

Если ваша база КД развернута в клиент-серверном варианте (например, под управлением MS SQL Server или PostgreSQL), мы можем точно определить, какой именно объект вызывает конфликт СУБД.

Выполним диагностику:

В тексте ошибки СУБД обычно указывает шестнадцатеричное представление неуникального ключа (GUID). Например: 0x80e600155d05070111e389a912ab4cd5.
Подключимся к базе данных через консоль управления СУБД и выполним запрос к таблице, указанной в ошибке (предварительно выяснив соответствие физической таблицы _Reference16 объекту метаданных КД с помощью функции ПолучитьСтруктуруХраненияБазыДанных()).

Пример SQL-запроса для поиска проблемной записи:


SELECT * 
FROM _Reference16 
WHERE _IDRRef = 0x80e600155d05070111e389a912ab4cd5;

Анализ полученной строки поможет нам точно определить, какой справочник или реквизит метаданных КД пытается перезаписать поверх существующей некорректной ссылки. После этого мы можем либо удалить эту запись средствами платформы 1С через поиск и замену дублей, либо исправить коллизию в исходной конфигурации-источнике.

Используя приведенные методики, мы гарантированно сможем обойти системную ошибку КД 2.1 и успешно продолжить разработку правил интеграции.