При масштабных обновлениях или попытках привести доработанную конфигурацию к типовому виду (например, при подготовке к переходу с КА 1.1 на КА 2.4) программисты часто сталкиваются с критической ошибкой платформы: «Записи регистра сведений стали неуникальными». Эта проблема блокирует реструктуризацию базы данных и не позволяет завершить обновление. Давайте детально разберем, почему это происходит и как исправить ситуацию, даже если стандартное «Тестирование и исправление» не помогает.
Прежде чем приступать к радикальным мерам, нам необходимо понять механику возникновения этой ошибки. Она появляется в тот момент, когда платформа 1С пытается создать уникальный индекс в таблице СУБД (SQL Server или PostgreSQL), но обнаруживает, что две или более записи имеют идентичный набор значений в полях, входящих в состав измерений.
Проанализируем основные сценарии, почему это происходит:
NULL или пустые ссылки, создавая массовые дубли.DBSchema платформа может «видеть» данные, которые не отображаются в пользовательском интерфейсе.Первым делом нам нужно убедиться, что структура регистра в нашей базе действительно совпадает с типовой. Рассмотрим, как это сделать правильно. Мы не просто смотрим на состав полей, а используем механизм «Сравнение, объединение с конфигурацией поставщика». Нам нужно обратить внимание на:
Если в вашей версии регистра присутствуют лишние измерения, которых нет в типовой, именно их удаление при реорганизации приводит к схлопыванию записей в дубли.
Если регистр кажется пустым или вы не видите дублей глазами, это не значит, что их нет на уровне базы данных. Попробуем программно найти записи, которые конфликтуют. Для этого можно использовать несложный запрос. Разберем пример кода для консоли запросов, который поможет найти дубли в регистре АвансыРаботниковОрганизаций:
ВЫБРАТЬ
Регистр.Период,
Регистр.Сотрудник,
Регистр.Организация,
КОЛИЧЕСТВО(*) КАК КоличествоДублей
ИЗ
РегистрСведений.АвансыРаботниковОрганизаций КАК Регистр
СГРУППИРОВАТЬ ПО
Регистр.Период,
Регистр.Сотрудник,
Регистр.Организация
ИМЕЮЩИЕ
КОЛИЧЕСТВО(*) > 1
Если запрос возвращает строки, значит, физические дубли существуют. Их необходимо удалить перед запуском реструктуризации.
Существует мощный профессиональный инструмент для решения подобных проблем — «Подготовка к изменению структуры БД» (автор Сергей Старых, известный как tormozit). Рассмотрим, чем он может нам помочь:
Это самый эффективный способ, когда ошибка «прыгает» с одного регистра на другой. Проанализируем всю конфигурацию целиком с помощью этого инструмента, чтобы не чистить каждый регистр вручную.
Если регистр выдает ошибку даже будучи «пустым» в интерфейсе 1С, нам придется прибегнуть к методу полной очистки через SQL или полную пересоздачу объекта. Разберем этот алгоритм по шагам:
ОбменДанными.Загрузка = Истина. При записи дублирующие записи просто не запишутся или перезапишут друг друга, и уникальность не будет нарушена.Бывают случаи, когда для 1С записи разные (например, «Иванов » и «Иванов»), а для SQL Server они одинаковые из-за настроек сопоставления (Collation). Проанализируем строковые измерения на наличие пробелов в конце строк или символов переноса строки. Выясним причину с помощью SQL-запроса, если у вас есть доступ к консоли СУБД:
-- Пример для поиска строк, которые станут одинаковыми при обрезке пробелов
SELECT [_Fld1234], COUNT(*)
FROM [_InfoReg5678]
GROUP BY LTRIM(RTRIM([_Fld1234]))
HAVING COUNT(*) > 1
Где _InfoReg5678 — имя таблицы вашего регистра в SQL, а _Fld1234 — имя поля измерения. Если такие записи найдены, их нужно нормализовать (удалить лишние пробелы) внутри 1С перед обновлением.
Ошибка уникальности — это всегда следствие несоответствия данных новой структуре метаданных. Помните: простое удаление данных — это крайний метод. Всегда начинайте с анализа состава измерений через сравнение конфигураций и использования специализированных инструментов разработчика. Это сэкономит время и сохранит целостность вашей базы данных.