Как исправить ошибку «Имеются записи с одинаковыми измерениями» при настройке регистра сведений в 1С?

При реструктуризации базы данных, включении индексирования или изменении структуры независимого периодического регистра сведений разработчики нередко сталкиваются с ошибкой «Имеются записи с одинаковыми измерениями». Давайте подробно разберем, по каким правилам платформа 1С контролирует уникальность записей, почему стандартные SQL-скрипты очистки могут не видеть дубликаты и как правильно устранить эту проблему.

Принцип формирования уникальности записей регистра сведений

Проанализируем ключевое правило платформы: в независимом периодическом регистре сведений уникальный ключ записи формируется строго из поля Период и всех полей измерений. Значения ресурсов и реквизитов в проверке уникальности не участвуют.

Частая ошибка при попытке ручной очистки таблиц базы через SQL — поиск дублей по связке «Период + Измерения + Ресурсы». Если в один и тот же момент времени для одного товара записаны две разные цены, то с точки зрения бизнес-логики строки кажутся разными, но для платформы 1С это критический конфликт уникальности.

Поиск и удаление дубликатов на уровне SQL Server

Рассмотрим, как правильно составить запрос к таблице СУБД для поиска неуникальных записей. Для независимого регистра с периодичностью «В пределах секунды» группировку необходимо выполнять исключительно по полям измерений и периоду:

SELECT 
    вз.Период, 
    вз.Товар, 
    вз.КоличествоДублей
FROM (
    SELECT 
        _Period AS Период,
        _Fld1234_RRRef AS Товар,
        COUNT(1) AS КоличествоДублей
    FROM dbo._InfoRg1234
    GROUP BY _Period, _Fld1234_RRRef
) вз
WHERE вз.КоличествоДублей > 1;

После выявления дубликатов лишние строки удаляются с сохранением только одной актуальной записи для каждой комбинации периода и измерения.

Скрытые причины конфликтов уникальности при работе с СУБД

Если SQL-запрос больше не возвращает дубликатов, но платформа 1С по-прежнему выдает ошибку при реструктуризации, разберем технические нюансы взаимодействия платформы и СУБД:

1. Миллисекунды в поле даты: Платформа 1С работает с датами с точностью до одной секунды. Однако тип данных DATETIME в MS SQL Server хранит миллисекунды. Если данные загружались или правились прямыми запросами в обход объектной модели 1С, в базе могли появиться записи с разницей в доли секунд (например, 12:00:00.100 и 12:00:00.500). Для SQL Server это разные строки, но при реструктуризации 1С отсекает миллисекунды, что приводит к возникновению дублей. Для поиска таких записей в SQL приведем дату к формату без миллисекунд:
   Скопировать код

   
   SELECT 
       CONVERT(VARCHAR(19), _Period, 120) AS ПериодСекунды,
       _Fld1234_RRRef AS Товар,
       COUNT(1) AS Дублей
   FROM dbo._InfoRg1234
   GROUP BY CONVERT(VARCHAR(19), _Period, 120), _Fld1234_RRRef
   HAVING COUNT(1) > 1;
   

2. Особенности ссылок на внешние источники данных: Если измерение имеет тип ссылки на таблицу внешнего источника данных (например, ВнешнийИсточникДанныхТаблицаСсылка...), на уровне СУБД ссылка может храниться в виде нескольких служебных колонок или строкового ключа. «Битые» ссылки, для которых удалена запись во внешнем источнике, платформа при реструктуризации может приводить к единому пустому значению, что мгновенно порождает дубликаты.
3. Концевые пробелы в строковых ключах (PAD_SPACE): Если первичный ключ внешнего источника строковый, MS SQL Server при выполнении GROUP BY может игнорировать замыкающие пробелы, считая строки одинаковыми, тогда как бинарный уникальный индекс платформы воспринимает их иначе. Для точного анализа используем функцию DATALENGTH() вместо LEN().

Методика гарантированного устранения проблемы через 1С

Разберем по шагам безопасный алгоритм решения проблемы, если прямой доступ к СУБД не дает нужного результата:

1. Локализация конфликта через Технологический журнал: Настроим сбор событий EXCP и DBMSSQL. При падении реструктуризации в логе зафиксируется точная ошибка СУБД (например, Violation of UNIQUE KEY constraint) с перечнем конфликтующих значений полей.
2. Выгрузка и перезапись через объектную модель: Создадим внешнюю обработку, которая считает данные через РегистрСведенийНаборЗаписей или объектный запрос, выгрузит их во временную структуру, очистит проблемный регистр, а затем выполнит обратную запись. Платформа 1С при стандартной записи набора автоматически перезапишет дублирующиеся ключи в соответствии с правилами регистра.
3. Корректировка архитектуры регистра: Если бизнес-логика требует хранения нескольких изменений ресурса в пределах одной секунды, добавим в регистр дополнительное измерение (например, НомерСтроки с типом Число или ИдентификаторЗаписи с типом УникальныйИдентификатор), либо переведем регистр в режим «Подчинение регистратору».