Ошибка уникальности записей регистра сведений при загрузке конфигурации: причины и решение

При работе с базами данных 1С, имеющими длительную историю (10–15 лет), программисты часто сталкиваются с парадоксальной ситуацией. При попытке привести сильно измененную конфигурацию к типовому виду путем загрузки файла .cf система выдает критическую ошибку: «Записи регистров сведений стали не уникальными». При этом физическая очистка регистра или даже его полное удаление в конфигурации не всегда помогают — ошибка может «мигрировать» на следующий объект. Рассмотрим подробнее, почему это происходит и как правильно выполнить «лечение» базы.

Почему возникает ошибка при «чистых» данных?

Разберем ситуацию, когда данные в регистре визуально корректны или вовсе отсутствуют, но платформа 1С все равно сообщает о нарушении уникальности. Основная причина кроется не в самих записях, а в механизме идентификации объектов метаданных.

Внутренняя логика платформы 1С:Предприятие опирается не на строковые имена объектов (например, «Склад» или «Номенклатура»), а на их внутренние идентификаторы — UUID (GUID). Если база развивалась долгие годы, проходила через конвертации версий (с 8.0 на 8.1, затем на 8.2 и 8.3) или в ней вручную создавались объекты, которые «по названию» совпадают с типовыми, их UUID почти наверняка будут отличаться от тех, что хранятся в эталонном файле .cf.

Проанализируем процесс реструктуризации при загрузке конфигурации:

1. Платформа сопоставляет объекты из файла .cf и объекты текущей базы по UUID.
2. Если UUID измерения регистра в базе не совпадает с UUID в файле, 1С считает, что старое измерение нужно удалить, а новое — создать.
3. В процессе реструктуризации на уровне SQL-таблицы создаются новые колонки. По умолчанию они заполняются пустыми значениями (для ссылочных типов — это пустая ссылка, для чисел — 0).
4. Если в регистре было более одной записи, то после «удаления» старых измерений и «создания» новых все записи превращаются в идентичные строки, состоящие из пустых значений.
5. При попытке системы создать индекс уникальности по измерениям (Primary Key на уровне СУБД) возникает коллизия: записи дублируются, и операция прерывается.

Метод №1: Синхронизация UUID через «Сравнение и объединение»

Это основной и самый безопасный способ заставить платформу «узнать» старые объекты и связать их с новыми идентификаторами без потери структуры данных. Рассмотрим пошаговый алгоритм:

Шаг 1. Предварительное сопоставление. Вместо функции «Загрузить конфигурацию из файла», используйте «Конфигурация — Сравнить, объединить с конфигурацией из файла».

Шаг 2. Настройка соответствий. В открывшемся окне сравнения необходимо снять все флажки (чтобы не вносить изменения в код и структуру преждевременно). Основная цель — вызвать диалог постановки на поддержку или связывания объектов.

Шаг 3. Установка соответствий вручную. Если объекты не сопоставились автоматически, нажмите правую кнопку мыши на проблемном регистре или его измерениях и выберите пункт «Установить соответствие». Выберите соответствующий объект из файла поставщика. Это принудительно запишет UUID из файла в вашу базу метаданных.

Шаг 4. Применение изменений. Нажмите «Выполнить». Платформа обновит внутренние идентификаторы, связав их с именами. После этого повторная попытка загрузки .cf или обновления конфигурации БД должна пройти без ошибок уникальности, так как реструктуризация будет понимать, что измерения не меняются.

Метод №2: Проверка «фантомных» записей на уровне SQL

Иногда проблема действительно кроется в данных, которые «не видит» конфигуратор из-за повреждения итогов или индексов. В этом случае нам поможет прямой запрос к СУБД. Выясним причину дублей с помощью группировки по измерениям. Рассмотрим пример запроса для MS SQL Server (имена таблиц и полей нужно предварительно получить через функцию ПолучитьСтруктуруХраненияБазыДанных()):

SELECT 
    _Fld123, -- Измерение 1 (например, Номенклатура)
    _Fld124, -- Измерение 2 (например, Склад)
    COUNT(*) 
FROM 
    dbo._InfoReg456 
GROUP BY 
    _Fld123, _Fld124 
HAVING 
    COUNT(*) > 1;

Если запрос возвращает строки, значит, в базе физически присутствуют дубли. Их необходимо удалить средствами SQL или через специальную обработку в 1С (написав запрос к менеджеру регистра сведений), прежде чем запускать обновление.

Метод №3: Очистка системных таблиц конфигурации

Если регистр пуст, UUID сопоставлены, но ошибка сохраняется, проблема может быть в кэше метаданных, который хранится в системных таблицах Config и ConfigSave. Для исправления ситуации проанализируем следующий подход:

1. Выгрузите базу в файл .dt.
2. Создайте новую пустую базу на сервере 1С.
3. Загрузите .dt в новую базу.

При выгрузке/загрузке .dt платформа полностью пересобирает структуру SQL-таблиц и очищает «мусорные» записи в системных таблицах, что часто решает проблему «невидимых» ошибок уникальности.

Рекомендации для баз с большим «наследием»

Для конфигураций, которые не обновлялись должным образом со времен платформы 8.0/8.1, рекомендуется использовать метод «промежуточного релиза». Не пытайтесь сразу накатить современный .cf. Попробуйте сначала обновиться до промежуточной версии (например, соответствующей релизу 5-7 летней давности), выполнить полную реструктуризацию (ТиИ), и только затем переходить к финальной версии конфигурации.

Также важно убедиться, что файл .cf, который вы загружаете, является «чистым» (выгруженным из типовой конфигурации той же версии), и в нем нет своих внутренних логических ошибок. Проверьте его через «Тестирование и исправление» в отдельной пустой базе перед использованием на рабочей системе.

Резюмируем: Основной инструмент решения проблемы — процедура сравнения и объединения для восстановления связей между объектами по их именам и UUID. Это позволяет избежать ошибочного удаления и создания колонок в SQL-таблицах, что и является истинной причиной возникновения «фантомных» дублей при обновлении.