← На главную

Нередко после установки очередного релиза типовой или отраслевой конфигурации (например, 1С:WMS Логистика) пользователи сталкиваются с критическими ошибками в рабочих процессах. Первое инстинктивное желание администратора базы данных — быстро вернуть все назад, применив файл поставки предыдущей версии (.cf) через меню сравнения и объединения. Однако такой подход практически всегда приводит к еще более серьезным проблемам: перестают сравниваться общие модули, пропадают XDTO-пакеты, а база отказывается запускаться в режиме «1С:Предприятие».

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

Почему откат через файл cf приводит к ошибкам

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

1. Отработавшие обработчики обновления данных. При первом старте после обновления релиз запускает отложенные или явные процедуры миграции данных. Платформа заполняет новые реквизиты, переносит остатки в измененные регистры и сворачивает устаревшие структуры. Если мы накатываем старый .cf, то возвращаем только программный код и структуру объектов, но сами данные в таблицах СУБД остаются сконвертированными под новый релиз. Старый программный код пытается обратиться к прежним полям и таблицам, которых уже нет, что вызывает критические сбои и фатальные ошибки.
2. Блокировка запуска контролем версий подсистем. В конфигурациях факт успешного перехода на новую версию фиксируется в регистре сведений ВерсииПодсистем. Механизмы БСП запрещают так называемый «downgrade» (понижение версии конфигурации). При попытке войти в режим предприятия система выведет ошибку о том, что номер версии конфигурации в метаданных меньше, чем зарегистрированный в базе данных.
3. Специфика сравнения XDTO-пакетов и модулей. Механизм сравнения конфигураций сопоставляет XDTO-пакеты не только по именам, но и по URI пространств имен (Target Namespace). Если в обновленном релизе поставщик скорректировал URI или структуру пакета, конфигуратор не может сопоставить их автоматически, из-за чего изменения пропускаются. Кроме того, на результат сравнения часто влияют кэш конфигуратора и фильтры правил поддержки (наличие признака «желтого замка» без права редактирования).
4. Необратимая потеря реквизитов. Если пользователи успели поработать в новой конфигурации и заполнили реквизиты, добавленные новым релизом, то при возврате к старой схеме метаданных платформа удалит эти колонки из таблиц СУБД в процессе реструктуризации базы данных.

Вариант 1. Восстановление резервной копии с переносом накопленных данных (рекомендуемый)

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

Разберем пошаговый алгоритм действий:

1. Изоляция контура. Завершим все пользовательские сеансы и заблокируем регламентные задания в текущей рабочей базе с ошибками.
2. Развертывание резервной копии. Развернем из бэкапа копию базы данных, которая находилась на стабильном релизе до обновления. Это будет наша будущая основная рабочая база.
3. Выгрузка изменений из проблемной базы. Откроем обновленную базу (где пользователи уже успели поработать). С помощью специализированных инструментов (например, встроенной обработки «Выгрузка и загрузка данных XML» или механизма планов обмена) отберем и выгрузим во внешний XML-файл только те объекты, которые были созданы или модифицированы с момента обновления. В первую очередь это документы, задачи, связанные с ними записи регистров сведений и новые элементы справочников.
4. Загрузка данных в восстановленную базу. Запустим развернутую предрелизную базу и загрузим сформированный XML-пакет. Поскольку структура метаданных в этой базе полностью совпадает со старыми документами, данные лягут без конфликтов формата.
5. Проведение и актуализация движений. Выполним групповое перепроведение перенесенных документов, чтобы восстановить корректные движения по складским и учетным регистрам.

Такой подход полностью исключает несоответствие между программным кодом конфигурации и физической структурой таблиц в базе данных.

Вариант 2. Локализация и исправление ошибок вместо отката

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

1. Анализ журнала регистрации. Внимательно изучим системный Журнал регистрации, отфильтровав события по уровню «Ошибка». Выясним, на каких именно процедурах и методах происходит сбой.
2. Использование механизма расширений. Чтобы не снимать типовую конфигурацию с поддержки и не вносить изменения в основной код поставщика, исправим проблемные методы общих модулей или формы через расширение конфигурации (с директивами &Вместо, &После или &Перед). Это позволит быстро вернуть склад к нормальной работе.
3. Проверка отложенных обработчиков. Откроем форму «Результаты обновления программы» (в разделе администрирования). Убедимся, что все регламентные фоновые процедуры обновления успешно завершены. Нередко ошибки возникают именно из-за того, что система пытается обращаться к данным, которые еще не успели мигрировать в фоновом режиме.

Вариант 3. Принудительный возврат метаданных при отсутствии новых данных

Если пользователи не вносили никаких данных в режиме предприятия, но при попытке вернуть старую конфигурацию через Сравнить, объединить с конфигурацией из файла возникают проблемы с XDTO-пакетами и общими модулями, типовое сравнение/объединение использовать не следует.

Рассмотрим, как правильно вернуть исходное состояние конфигурации через полное замещение:

1. Очистка кэша конфигуратора. Закроем конфигуратор и очистим каталоги временных файлов платформы (пользовательский кэш 1cv8 в директориях %LOCALAPPDATA% и %APPDATA%). Это снимет проблему со сбоями отображения измененного кода модулей.
2. Загрузка конфигурации целиком. Вместо инструмента объединения используем команду главного меню: Конфигурация -> Загрузить конфигурацию из файла... и укажем файл поставки стабильной версии .cf. Данная операция полностью перезаписывает дерево объектов, включая модули, роли, конфигурацию поставщика и XDTO-пакеты, устраняя любые конфликты слияния.
3. Корректировка регистра версий подсистем. После применения изменений структуры метаданных перейдем в режим «1С:Предприятие». Если при старте появляется блокирующее предупреждение о понижении версии, необходимо открыть список регистра сведений ВерсииПодсистем (через панель «Функции для технического специалиста») и вручную установить номера версий, соответствующие загруженному релизу.

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