Как исправить критическую ошибку со значением NULL при обновлении файловой базы 1С?

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

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

Причины возникновения ошибки реструктуризации

Проанализируем внутренний механизм обновления структуры базы данных. При изменении состава или свойств реквизитов платформа 1С выполняет реструктуризацию: создает новую временную таблицу целевого формата и переносит в нее данные из старой таблицы. На этом этапе могут возникнуть сложности:

1. Недопустимые значения NULL на физическом уровне: если на реквизит в новом релизе накладывается системное ограничение NOT NULL, а в исходной таблице присутствуют записи с незаполненными полями, операция копирования прерывается аварийно.
2. Обход валидации при обмене данными: распространенный источник проблемы — загрузка данных через планы обмена. При программной записи с установленным свойством ОбменДанными.Загрузка = Истина типовые проверки модулей объектов (события ПередЗаписью и ПриЗаписи) отключаются. В базу могут попасть «полупустые» элементы, содержащие только код или наименование без обязательных системных реквизитов.
3. Ограниченность утилиты chdbfl: утилита проверки файла .1CD контролирует только физическую целостность страниц и блоков файла, но не проверяет логическую целостность и бизнес-ограничения прикладных данных.

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

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

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

ТаблицаХранения = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
ИскомоеПоле = "_Fld985";

Для Каждого СтрТаблица Из ТаблицаХранения Цикл
    Для Каждого СтрПоле Из СтрТаблица.Поля Цикл
        Если ВРег(СтрПоле.ИмяПоляХранения) = ВРег(ИскомоеПоле) Тогда
            Сообщить("Объект метаданных: " + СтрТаблица.Имя);
            Сообщить("Реквизит: " + СтрПоле.Имя);
            Прервать;
        КонецЕсли;
    КонецЦикла;
КонецЦикла;

Шаг 2. Поиск и исправление некорректных записей

Выяснив, в каком объекте (например, справочнике Организации или КодыОКПД) произошел сбой, проверим данные на наличие некорректных записей. Чаще всего сбой вызывают элементы, записанные без ключевых реквизитов.

Разберем по шагам алгоритм поиска и перезаписи таких объектов:

1. Анализ содержимого через консоль запросов: выполним выборку всех элементов подозрительного справочника, включая системные поля (код, наименование, пометка удаления, ссылки на связанные справочники).
2. Проверка заполнения: напишем обработку, которая программно считывает объекты и проверяет их стандартным методом ПроверитьЗаполнение().
3. Принудительная перезапись с включенным контролем: перезапишем объекты с параметром ОбменДанными.Загрузка = Ложь. Это инициирует заполнение значений по умолчанию и выявит ошибки валидации до запуска реструктуризации.

Выборка = Справочники.Организации.Выбрать();
Пока Выборка.Следующий() Цикл
    Объект = Выборка.ПолучитьОбъект();
    Попытка
        // Отключаем режим обмена, чтобы сработали типовые проверки модуля объекта
        Объект.ОбменДанными.Загрузка = Ложь;
        Если Не Объект.ПроверитьЗаполнение() Тогда
            Сообщить("Найден некорректный элемент: " + Объект.Ссылка + " (Код: " + Объект.Код + ")");
        КонецЕсли;
        Объект.Записать();
    Исключение
        Сообщить("Ошибка при записи объекта: " + ОписаниеОшибки());
    КонецПопытки;
КонецЦикла;

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

Альтернативные способы восстановления базы данных

Если поиск битых записей встроенными средствами затруднен, рассмотрим дополнительные варианты решения проблемы:

1. Тестирование и исправление с исправлением ссылок: запустим в Конфигураторе Администрирование -> Тестирование и исправление... с обязательной установкой флагов «Проверка логической целостности» и «Проверка ссылочной целостности». В переключателях при наличии ссылок на несуществующие элементы выберем вариант «Создавать объекты» или «Очищать ссылки».
2. Выгрузка и загрузка данных через XML: создадим чистую информационную базу целевого релиза конфигурации и перенесем данные с помощью универсальной обработки «ВыгрузкаЗагрузкаДанныхXML». При загрузке в чистую базу все физические таблицы и индексы формируются заново, исключая поврежденные внутренние записи.
3. Очистка таблиц регистрации изменений: если некорректные записи попали в состав очереди плана обмена, очистим регистрацию изменений по проблемному объекту перед повторным накатыванием файла обновления (.cf / .cfu).

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