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

← На главную

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

Выясняем причину: почему возникает ошибка?

Для начала проанализируем структуру регистра сведений ДвоичныеДанныеФайлов. Этот регистр предназначен для хранения содержимого присоединенных файлов в базе данных. Он имеет ключевую особенность: у него есть только одно измерение — Файл. Тип этого измерения задан как ОпределяемыйТип.ПрисоединенныйФайл.

Этот определяемый тип является составным. В него входят ссылки на все справочники присоединенных файлов, существующие в системе (например, Справочник.ДоговорыКонтрагентовПрисоединенныеФайлы, Справочник.НоменклатураПрисоединенныеФайлы и так далее).

Рассмотрим по шагам механизм, который приводит к ошибке реструктуризации:

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

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

Шаг 1. Локализация проблемы и поиск виновников

Прежде чем приступать к исправлению, нам необходимо понять, какие именно записи вызывают сбой. Если проблема вызвана «битыми» ссылками (объектами, которые были удалены непосредственно, минуя стандартные механизмы очистки), мы можем обнаружить их простым запросом.

Запустим консоль запросов и выполним следующий код:


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

Если этот запрос вернул строки, значит, в базе физически присутствуют дубликаты. Их можно удалить вручную или с помощью простой обработки. Но если запрос пуст, а ошибка реструктуризации всё равно возникает, то дело именно в изменении состава типов ОпределяемыйТип.ПрисоединенныйФайл.

Выяснить, какие именно типы были удалены, можно путем сравнения исходной конфигурации (до обновления) и новой конфигурации поставщика. Обратите внимание на список типов в свойстве определяемого типа ПрисоединенныйФайл.

Шаг 2. Варианты решения проблемы

Рассмотрим несколько надежных практических способов устранения этой ошибки, начиная от самых быстрых «лайфхаков» и заканчивая фундаментальными методами очистки данных.

Способ А. Временное добавление дополнительного ресурса (быстрый обход)

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

Откройте конфигуратор и найдите регистр сведений ДвоичныеДанныеФайлов.
Разрешите изменение этого регистра (установите режим «Редактируется с сохранением поддержки»).
Добавьте в регистр новый ресурс. Назовем его, например, ВременныйРесурс с типом данных Число или Строка.
Выполните обновление конфигурации базы данных (клавиша F7).

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

Способ Б. Выгрузка, очистка и обратная загрузка данных

Если первый способ по каким-то причинам не помог или записей с битыми типами слишком много, применим радикальный, но абсолютно безопасный метод очистки регистра на время обновления.

Рассмотрим алгоритм действий:

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


НаборЗаписей = РегистрыСведений.ДвоичныеДанныеФайлов.СоздатьНаборЗаписей();
НаборЗаписей.Записать(Истина);

Запустим обновление конфигурации в конфигураторе. Оно пройдет мгновенно и без ошибок, так как пустой регистр не содержит записей для сопоставления.
После успешного обновления запустим обратный процесс загрузки данных из нашего файла. При загрузке те записи, ссылки которых теперь стали недопустимыми (так как их тип был удален из определяемого типа), просто запишутся как одна пустая запись (или будут пропущены в зависимости от логики вашего кода загрузки), а все остальные файлы восстановятся в полном объеме.

Способ В. Восстановление метаданных в определяемом типе

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

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

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

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