Среди системных администраторов и начинающих программистов часто возникает соблазн ускорить процесс обновления разветвленной сети баз 1С. Идея звучит логично: зачем тратить часы на последовательное обновление каждой рабочей базы, если можно сделать это один раз на копии, выгрузить итоговый файл .cf и просто "накатить" его на все оригинальные базы в магазинах или филиалах? Рассмотрим эту ситуацию детально, проанализируем скрытые угрозы и выясним, как правильно выстроить процесс обновления, чтобы не получить нерабочую систему.
На первый взгляд, если конфигурация в базе-приемнике идентична той, что вы подготовили, система должна работать корректно. Однако разработчики платформы и типовых решений категорически не советуют "перепрыгивать" через рекомендуемые релизы цепочки обновлений. Разберем по шагам, почему простая замена структуры базы может привести к фатальным ошибкам.
Самая большая опасность кроется не в изменении структуры таблиц SQL или файловой базы, а в пропуске обработчиков обновления данных. В современных решениях, построенных на базе Библиотеки стандартных подсистем (БСП), процесс обновления делится на два этапа:
Проанализируем пример: в релизе "А" разработчик 1С решил переименовать реквизит справочника. В релизе "Б" он написал код, который переносит данные из старого реквизита в новый. В релизе "В" старый реквизит физически удаляется. Если вы обновите базу пошагово, система корректно переместит информацию. Но если вы возьмете файл .cf от релиза "В" и сразу загрузите его в базу с релизом "А", система просто удалит старый реквизит вместе со всеми данными, так как промежуточный обработчик из релиза "Б" никогда не запустится. В результате вы получите "битые" ссылки, пустые обязательные поля или полностью нерабочую базу (превратите ее в "кирпич").
Посмотрим на инструменты, которые предоставляет Конфигуратор для работы с файлами конфигурации. Важно четко понимать разницу между двумя основными командами:
1. Загрузить конфигурацию из файла
Эта команда полностью и безусловно заменяет текущую структуру базы на ту, что находится в файле .cf. Идентификаторы объектов могут сопоставиться некорректно, если в базах были даже минимальные отличия во внутренних ID. Это самый быстрый, но и самый опасный путь для рабочей информационной базы. Эту команду безопасно использовать только для пустых баз или при откате на резервную копию того же самого релиза.
2. Обновить конфигурацию (через поддержку или сравнение)
При выборе файла .cf в качестве файла обновления, платформа 1С детально анализирует изменения, сопоставляет объекты по их уникальным идентификаторам и формирует корректный план реструктуризации базы данных. Это единственно правильный метод наката изменений.
Если ваша инфраструктура (например, сеть магазинов) построена на технологии РИБ, подход к обновлению радикально меняется. В распределенных базах новая конфигурация автоматически "прилетает" с ближайшим обменом из центрального узла в периферийную базу.
Рассмотрим, что произойдет, если вы обновите центральную базу (ЦБ) сразу на несколько релизов вперед путем загрузки .cf:
Для решения проблем с обменами в РИБ при тяжелых обновлениях, системные администраторы часто применяют метод временной отвязки узла. Рассмотрим этот скрипт запуска, который позволяет отвязать базу от главного узла для ручного обновления:
// Пример параметров командной строки для запуска 1С
// с целью временного сброса главного узла РИБ
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F"C:\Bases\Shop1" /ResetMasterNode
После отвязки узла, в него загружается идентичный файл .cf, после чего узел снова привязывается к центру (для этого существуют специальные обработки восстановления связи РИБ). Но помните, что это крайняя мера.
В обсуждении упоминается конфигурация от разработчика "Рарус". Проанализируем специфику таких систем. Отраслевые решения часто используют системы лицензирования и защиты кода (например, СЛК), а часть модулей в них зашифрована.
Если вы обновите базу не через официальный установщик (который помимо конфигурации обновляет драйверы защиты на сервере), а через слепой перенос файла .cf, вы рискуете столкнуться с тем, что обновленная конфигурация потребует новую версию сервера лицензирования. Метаданные обновятся успешно, Конфигуратор закроется без ошибок, но при запуске Предприятия система выдаст критическую ошибку защиты и не пустит пользователей.
Выясним причину множества фантомных ошибок, которые появляются после резкой подмены конфигурации. Платформа 1С агрессивно кэширует формы, модули и запросы на локальных компьютерах пользователей для ускорения работы.
При использовании штатного механизма пошагового обновления, платформа корректно инвалидирует кэш. Но при жесткой заливке файла .cf старые формы могут "застрять" в локальных папках Windows. Это приводит к ошибкам вида "Метод объекта не обнаружен" или аварийному закрытию программы. После таких манипуляций обязательным шагом является очистка кэша на всех клиентских машинах (удаление информационной базы из списка запуска и добавление ее заново, либо очистка папок в AppData).
Если ситуация безвыходная (сильное отставание по релизам) и вы принимаете на себя риски, воспользуйтесь следующим комбинированным алгоритмом, который минимизирует шанс потери данных. Выполним по шагам:
.cf..cf. Не используйте команду "Загрузить конфигурацию"!ЗапуститьОбновлениеИнформационнойБазы).Для минимизации времени простоя магазинов, в современных версиях платформы (начиная с 8.3) настоятельно рекомендуем использовать механизм фонового обновления конфигурации базы данных. Он позволяет выполнять тяжелые операции изменения таблиц СУБД в то время, когда пользователи еще работают в системе, блокируя базу лишь на финальные несколько минут для применения изменений.
Подводя итог: обновление путем простого переноса конфигурации возможно и иногда применяется на практике, но является "экстремальным" методом. Он требует глубокого понимания архитектуры 1С, знания специфики вашей отраслевой программы и готовности к ручному исправлению поврежденных данных. В большинстве случаев надежнее и дешевле для бизнеса использовать стандартный, пошаговый механизм обновления от разработчика.