Почему при обновлении конфигурации из хранилища возникает ошибка «Записи регистра сведений стали неуникальными» и как её исправить?

← На главную

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

Основные причины возникновения ошибки при реструктуризации

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

Проанализируем скрытые причины, которые приводят к дублированию ключей:

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

Шаг 1. Диагностика и поиск дублирующихся записей

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

Посмотрим на пример текста диагностического запроса:


ВЫБРАТЬ
    Измерение1,
    Измерение2,
    Период,
    КОЛИЧЕСТВО(*) КАК КоличествоЗаписей
ИЗ
    РегистрСведений.ИмяРегистра
СГРУППИРОВАТЬ ПО
    Измерение1,
    Измерение2,
    Период
ИМЕЮЩИЕ
    КОЛИЧЕСТВО(*) > 1

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

Шаг 2. Проверка метаданных и битых ссылок

Разберем последовательность действий для устранения причин ошибки:

Детальная проверка типов: в окне сравнения и объединения конфигураций развернем свойства каждого измерения проблемного регистра и проверим состав типов данных. Убедимся, что ни один тип не был исключен из состава.
Тестирование и исправление: перед накатыванием изменений запустим в конфигураторе процедуру Тестирование и исправление информационной базы. Обязательно выберем пункты «Реиндексация таблиц информационной базы» и «Проверка логической и ссылочной целостности» с настройкой Очищать ссылки или Создавать объекты в случае обнаружения битых ссылок. Это позволит нормализовать поврежденные индексы и исключить ссылки на несуществующие объекты.

Шаг 3. Реструктуризация через выгрузку и загрузку данных

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

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

Таким образом, системный поиск битых ссылок, проверка состава типов измерений и тестирование информационной базы позволяют полностью решить проблему с неуникальными записями при обновлении конфигурации.