Как исправить ошибку «Записи регистра сведений стали неуникальными: ДвоичныеДанныеФайлов» при обновлении КА 2 с версии 2.2 на 2.4?

← На главную

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

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

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

Прежде всего, разберем технический парадокс: почему платформа сообщает о неуникальности записей в регистре ДвоичныеДанныеФайлов, если в версии 2.2.4 его нет? Дело в том, что в процессе обновления конфигуратор выполняет реструктуризацию. Он создает новые таблицы и пытается перенести в них данные из старых объектов метаданных, которые в новой версии помечены на удаление или переименованы.

Рассмотрим основные факторы, провоцирующие конфликт уникальности:

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

Решение 1: Выбор правильной цепочки релизов

Как показывает практика, не все релизы одинаково стабильны при конвертации данных. Проанализируем опыт пользователей: попытка прямого обновления с 2.2.4.227 на 2.4.3.170 часто завершается неудачей. Однако использование промежуточного или чуть более раннего релиза ветки 2.4 может решить проблему.

Рекомендуемый алгоритм действий:

Попробуйте выполнить обновление на релиз 2.4.3.160 вместо 2.4.3.170. Часто в конкретных сборках дистрибутивов обновления (cfu) содержатся ошибки в правилах сопоставления объектов.
Если база сильно изменена (доработана), крайне рекомендуется выполнять обновление не через cfu, а через сравнение/объединение с полным cf файлом нужного релиза, предварительно сняв базу с поддержки (или разрешив изменения).

Решение 2: Подготовка данных перед обновлением

Если смена релиза не помогла, необходимо «вылечить» данные в исходной базе 2.2.4. Разберем шаги по очистке базы от мусора, который мешает реструктуризации.

1. Тестирование и исправление (ТиИ):
Запустите конфигуратор и выполните «Тестирование и исправление» со следующими настройками:

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

2. Поиск записей с неопределенными владельцами:
Проанализируем состояние справочников присоединенных файлов. Нам нужно найти записи, у которых поле Владелец не заполнено или содержит объект, не входящий в состав типов. Рассмотрим пример кода для поиска проблемных мест (этот код нужно запустить в обработке в исходной базе):


// Пример поиска дублей в справочниках присоединенных файлов
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ПрисоединенныеФайлы.Ссылка КАК Файл,
    |   ПрисоединенныеФайлы.ВладелецФайла КАК Владелец
    |ИЗ
    |   Справочник.НоменклатураПрисоединенныеФайлы КАК ПрисоединенныеФайлы
    |ГДЕ
    |   ПрисоединенныеФайлы.ВладелецФайла = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка)";

Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
    Выборка = Результат.Выбрать();
    Пока Выборка.Следующий() Цикл
        // Здесь логика удаления или исправления
        Сообщить("Найден файл без владельца: " + Выборка.Файл);
    КонецЦикла;
КонецЕсли;

Решение 3: Использование инструментов анализа (ИР)

Для глубокого анализа проблемы рекомендуем воспользоваться Инструментами разработчика (ИР). В этом наборе инструментов есть специализированная проверка «Проверка перед усечением типов». Она позволяет до начала реструктуризации увидеть, какие именно записи превратятся в одинаковые из-за потери типа в измерении регистра.

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

Решение 4: Работа с SQL-транзакциями (для клиент-серверных баз)

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

Включите SQL Server Profiler перед нажатием кнопки «Принять» в конфигураторе.
Отследите последний запрос INSERT INTO или CREATE UNIQUE INDEX.
В тексте запроса вы увидите имена временных таблиц (начинаются с #tt...). По этим именам и значениям полей можно определить конкретные Internal ID объектов, вызывающих конфликт.

Важные замечания по аппаратной части

Обратите внимание на объем оперативной памяти на сервере 1С. Обновление «Комплексной автоматизации» — крайне ресурсоемкий процесс. Зафиксированы случаи, когда на серверах с объемом памяти менее 16-32 Гб процесс реструктуризации завершался некорректно, выдавая ошибки уникальности просто из-за прерывания транзакций кэширования. Убедитесь, что во время обновления на сервере достаточно свободного места и ресурсов.

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