Как исправить циклическую ошибку обновления информационной базы и перенести данные в чистую базу

← На главную

При длительной эксплуатации информационных баз 1С нередко возникает ситуация, когда обновления накатываются исключительно в конфигураторе через файлы поставки (.cf или .cfu), но запуск в режиме «1С:Предприятие» под администратором с выполнением обязательных процедур постобработки данных игнорируется. В результате при очередном входе система выдает сообщение: «Не выполнено обновление информационной базы. Завершить работу системы?». При этом физическое тестирование базы утилитой chdbfl.exe и стандартное тестирование и исправление (ТИИ) не выявляют никаких ошибок, так как таблицы целостны, а сбой происходит исключительно на уровне прикладного программного кода.

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

Почему конфигурация обновляется, а предприятие выдает ошибку

Выясним причину сбоя. Архитектура конфигураций, использующих «Библиотеку стандартных подсистем» (БСП) и отраслевые решения (например, «Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК»), разделяет процесс обновления на два этапа:

Обновление метаданных в конфигураторе — реструктуризация таблиц базы данных, добавление новых объектов метаданных, реквизитов и табличных частей.
Постобработка данных в режиме «1С:Предприятие» — выполнение процедур миграции, перерасчет и заполнение новых реквизитов, перенос остатков в новые регистры накопления и сведений, обновление служебных классификаторов.

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

Разработчики не хранят программный код обработчиков обновления старых версий бесконечно: спустя несколько релизов устаревшие процедуры удаляются из состава конфигурации. Когда база наконец пытается запуститься, алгоритм обновления обнаруживает в константе старый номер версии (к примеру, 2.0.64.14), пытается вызвать уже удаленные процедуры перехода, не находит их и аварийно завершает работу.

Ограничения обработки «Выгрузка и загрузка данных XML»

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

Строгое требование к идентичности метаданных. Обработка XML выполняет прямое чтение и запись сериализованных данных платформы. Загрузить данные из релиза редакции 2.0 напрямую в чистую базу редакции 3.0 (или из старого релиза в новый с изменившимся составом реквизитов) невозможно — процесс завершится ошибкой несоответствия структуры метаданных. Перенос возможен только в базу с абсолютно тем же релизом конфигурации.
Отключение прикладных проверок. При загрузке объектов через эту обработку свойство ОбменДанными.Загрузка устанавливается в значение Истина. Это отключает проверки в модулях объектов, что может зафиксировать логические ошибки в базе-приемнике.
Дублирование предопределенных элементов. В платформе «1С:Предприятие 8.3» предопределенные элементы хранятся в таблицах данных и связываются по свойству ИмяПредопределенныхДанных. При прямой выгрузке без сопоставления высок риск получить дубли: один системный элемент (пустой, созданный при первом запуске чистой базы) и второй — пользовательский с данными из старой базы. Получить имена системных элементов программно можно через вызов метаданных:


Для Каждого ТекСправочник Из Метаданные.Справочники Цикл
    ИменаПредопределенных = ТекСправочник.ПолучитьПредопределенныеИмена();
    Для Каждого ИмяЭлемента Из ИменаПредопределенных Цикл
        // Обработка предопределенного элемента
    КонецЦикла;
КонецЦикла;

Диагностика сбойного обработчика обновления

Прежде чем принимать решение о переносе данных, проанализируем, на каком именно этапе падает обновление. Для этого применим встроенные механизмы диагностики БСП:

Запуск отладки с остановкой по ошибке. Запустим конфигуратор, в меню «Отладка» включим пункт «Остановка по ошибке» и запустим сеанс в режиме «1С:Предприятие». При падении платформы мы сразу попадем в точку выполнения процедуры, вызвавшей исключение, и увидим стек вызовов.
Анализ регистра обработчиков. Если вход в режиме предприятия удается выполнить хотя бы в аварийном режиме или под полными правами, через меню «Функции для технического специалиста» откроем РегистрСведений.ОбработчикиОбновления. В нем отображаются все выполняемые процедуры, их статус, приоритет и подробный текст возникшей ошибки.
Командная строка запуска. Выполним запуск информационной базы с параметром принудительного обновления: 1cv8.exe ENTERPRISE /IBConnectionString "..." /C ЗапуститьОбновлениеИнформационнойБазы. Вся детализация процесса будет записана в Журнал регистрации.

Опасность ручной смены версии в константах

Иногда проблему решают установкой значения текущего релиза конфигурации в константу версии (например, НомерВерсииКонфигурации). После ручной перезаписи номера версии конфигурация перестает запускать обновление и вход в систему проходит без ошибок.

Обратим внимание на скрытые риски этого подхода:

Ручная смена версии не выполняет саму миграцию данных — она лишь отключает программный вызов процедур.
Все структуры, которые должны были заполниться за пропущенный период (новые расчетные регистры, пересчитанные остатки, соответствия лицевых счетов), остаются пустыми или некорректными.
В отраслевых решениях для ЖКХ пропуск миграции приводит к полному искажению начислений по приборам учета, сбоям формирования квитанций и невозможности выгрузки данных в ГИС ЖКХ из-за отсутствия обязательных системных связей.

Варианты правильного восстановления базы

Рассмотрим два безопасных пути решения проблемы в зависимости от масштаба повреждения данных.

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