В процессе администрирования и обновления типовых решений на платформе 1С:Предприятие 8.3 (например, конфигурации «Бухгалтерия предприятия, редакция 3.0») технические специалисты часто сталкиваются со следующей критической ошибкой при реструктуризации базы данных: «Записи регистра сведений стали неуникальными». Наиболее часто эта коллизия проявляется на регистрах, связанных с хранением присоединенных файлов и их двоичных данных, таких как ДвоичныеДанныеФайлов или ПрисоединенныеФайлы.
Уникальность ситуации заключается в том, что ошибка может возникать даже в тех случаях, когда целевой регистр сведений предварительно был абсолютно полностью очищен в режиме «1С:Предприятие» или напрямую через СУБД. В рамках данной статьи мы подробно разберем, почему возникает эта проблема, проанализируем внутренние механизмы платформы 1С и рассмотрим пошаговые сценарии её успешного решения.
Для того чтобы эффективно устранить сбой, нам необходимо понять физику процесса реструктуризации таблиц базы данных 1С. Когда платформа сообщает о неуникальности записей в абсолютно пустом регистре сведений, проблема кроется не в самих данных (информации), а в структуре метаданных и расхождении внутренних уникальных идентификаторов (GUID/UUID) объектов конфигурации.
Рассмотрим основные технические причины возникновения этой ошибки:
Ниже мы подробно разберем практические шаги по диагностике и устранению этой проблемы.
Прежде чем приступать к операциям с метаданными, нам необходимо убедиться, что в проблемном регистре действительно отсутствуют записи. Начнем с классической очистки набора записей программным путем. Запустим внешнюю обработку и выполним следующий код:
НаборЗаписей = РегистрыСведений.ДвоичныеДанныеФайлов.СоздатьНаборЗаписей();
НаборЗаписей.Записать(Истина);
ИнформационнаяОтладка = "Регистр успешно очищен на уровне платформы.";
ЗаписатьВЛог(ИнформационнаяОтладка);
Если после этого реструктуризация базы данных всё равно завершается ошибкой, это подтверждает гипотезу о расхождении метаданных (UUID) или наличии фантомных записей на уровне базы данных SQL. Если база данных клиент-серверная, системный администратор может выполнить команду полной очистки таблицы на уровне СУБД (предварительно сделав резервную копию базы данных!):
-- ВНИМАНИЕ: Выполнять только на копии базы данных!
-- Находим имя физической таблицы регистра (например, _InfoRg1234) и очищаем её
TRUNCATE TABLE _InfoRg1234;
Если ошибка сохраняется и после этого, переходим к анализу метаданных конфигурации.
Для исправления расхождения уникальных идентификаторов нам потребуется детально сравнить основную конфигурацию базы данных с чистой конфигурацией поставщика из файла поставки (расширение .cf). Проанализируем этот процесс по шагам:
Проанализируем результат. Если после отключения сопоставления по именам вы увидели, что стандартный регистр сведений ДвоичныеДанныеФайлов (или связанный с ним справочник присоединенных файлов) отображается в окне сравнения как два разных объекта (один присутствует только в конфигурации поставщика, другой — только в основной конфигурации), это указывает на явное расхождение UUID. Для платформы это два абсолютно разных регистра, несмотря на идентичные имена!
Если в вашей рабочей базе уже накоплено много реальных файлов и ручное удаление регистра невозможно, применим методику временного переименования дублирующих реквизитов и объектов. Разберем этот алгоритм:
Удалить_ (например, Удалить_ДвоичныеДанныеФайлов).Удалить_.Удалить_ДвоичныеДанныеФайлов в новый чистый регистр ДвоичныеДанныеФайлов. Пример шаблона кода для переноса данных рассмотрим ниже:
ВыборкаСтарыхДанных = РегистрыСведений.Удалить_ДвоичныеДанныеФайлов.Выбрать();
Пока ВыборкаСтарыхДанных.Следующий() Цикл
НоваяЗапись = РегистрыСведений.ДвоичныеДанныеФайлов.СоздатьМенеджерЗаписи();
ЗаполнитьЗначенияСвойств(НоваяЗапись, ВыборкаСтарыхДанных);
Попытка
НоваяЗапись.Записать(Истина);
Исключение
ЗаписьЖурналаРегистрации("ОшибкаПереноса", УровеньЖурналаРегистрации.Предупреждение,,,
"Не удалось перенести запись для файла: " + ВыборкаСтарыхДанных.File);
КонецПопытки;
КонецЦикла;
После успешного переноса данных и проверки работоспособности присоединенных файлов мы можем окончательно удалить объект Удалить_ДвоичныеДанныеФайлов из конфигурации и повторно выполнить реструктуризацию.
Если ваша база работает в распределенном режиме (РИБ), часто причиной сбоя уникальности при обновлении становятся «битые» ссылки. Платформа пытается построить индекс по измерению, содержащему ссылку на несуществующий элемент справочника файлов. Чтобы исправить это, выполним следующие действия:
После завершения тестирования платформа автоматически удалит записи регистров сведений, измерения которых ссылались на несуществующие «битые» файлы, что позволит успешно завершить обновление метаданных.
Мы детально разобрали сложную техническую коллизию неуникальности записей при обновлении конфигураций 1С. Чтобы минимизировать риски возникновения подобных ошибок в будущем, рекомендуем придерживаться нескольких простых правил: всегда выполняйте резервное копирование перед накатыванием релизов, детально контролируйте изменения UUID при ручном переносе объектов через сравнение-объединение и своевременно проводите профилактическое тестирование и исправление базы данных.