Каждый специалист по сопровождению 1С рано или поздно сталкивается с ситуацией, когда к нему в руки попадает база данных (например, 1С:Бухгалтерия предприятия), которую не обновляли несколько лет. Разница между текущим релизом базы и актуальным может составлять десятки, а то и сотни версий. В этот момент возникает сильное искушение «срезать углы»: взять финальный файл конфигурации cf последнего релиза, снять базу с поддержки, накатить его одним махом через функцию «Загрузить конфигурацию из файла» и запустить систему.
На первый взгляд, этот метод кажется гениально простым и быстрым. Но так ли это безопасно? Давайте подробно проанализируем, как устроен механизм обновления 1С изнутри, почему этот способ таит в себе колоссальные угрозы для данных и к каким катастрофическим последствиям для учета он может привести.
Для того чтобы понять опасность «прыжка» через один cf, разберем внутреннюю кухню современных конфигураций 1С, построенных на базе БСП (Библиотеки стандартных подсистем). Привычное нам обновление состоит из двух принципиально разных этапов:
БСП находит все зарегистрированные обработчики обновления (миграционные процедуры) для каждого пропущенного релиза и запускает их выполнение по строгой цепочке.Именно на втором этапе происходит магия переноса данных. Например, если разработчики 1С решили перенести учет основных средств из справочника ОС во вновь созданный регистр сведений, то специальный обработчик релиза X перепишет эти данные, а в релизе X+5 старый справочник или его реквизиты будут окончательно удалены из структуры за ненадобностью.
Когда мы загружаем финальный cf-файл, минуя промежуточные релизы, мы лишаем систему возможности корректно выполнить этот миграционный алгоритм. Рассмотрим основные технические причины сбоев:
Представим ситуацию: в релизе №1 у нас был реквизит СтавкаНДС. В релизе №5 разработчики решили переименовать его в СтавкаНДС_Устарела (или перенесли данные в другую таблицу), а в релизе №10 этот реквизит был полностью удален из метаданных конфигурации. Если мы обновляемся последовательно, то при переходе с 1 на 5 релиз отработает обработчик, который скопирует данные из старого реквизита в новый. Затем, на релизе 10, пустой старый реквизит благополучно удалится.
Если же мы сразу накатим cf релиза №10 на релиз №1, структура базы мгновенно лишится поля СтавкаНДС. Когда система попытается запустить обработчик обновления для перехода 1->5, этот код попробует обратиться к полю СтавкаНДС, не найдет его в СУБД и аварийно завершит работу с критической ошибкой. Итог — данные потеряны, обновление заблокировано.
Код старых обработчиков обновления выполняется в контексте нового программного кода (так как мы уже применили финальный cf). Если старый обработчик обновления обращается к процедуре или функции общего модуля (например, ОбщегоНазначения.ПолучитьЗначениеРеквизита), которая за это время была удалена, переименована или изменила состав параметров, выполнение прервется ошибкой компиляции. Процедура обновления «зависнет» окончательно.
Разработчики фирмы «1С» регулярно проводят ревизию кода БСП. Устаревшие обработчики обновлений (мигрирующие данные релизов пятилетней давности) со временем полностью удаляются из конфигурации. Если пропустить слишком много версий, в финальном cf просто не окажется кода, способного преобразовать древние данные вашей базы в новый формат. База данных просто «забудет», как обрабатывать ваши старые документы.
В истории развития любой типовой конфигурации существуют так называемые ключевые (или переходные) релизы. Это версии программы, в которых происходят кардинальные изменения структуры данных или переход на принципиально новые версии платформы и БСП. Накатить обновление поверх такого релиза без физического запуска базы в режиме «Предприятие» — гарантированный способ разрушить учет.
Золотое правило обновления: дойдя до ключевого релиза, мы обязаны запустить базу в режиме «1С:Предприятие», дождаться завершения работы всех монопольных и отложенных обработчиков обновления (убедившись в успешности процесса в журнале регистрации), и только после этого продолжать обновление на следующий этап.
Все процедуры миграции данных в современных версиях 1С делятся на два типа:
При попытке обновиться «одним прыжком» через загрузку cf, система пытается запустить гигантский пул накопленных отложенных обработчиков за все пропущенные релизы одновременно. Это неминуемо ведет к следующим проблемам:
Самое страшное при обновлении через «большой cf» заключается в том, что база может успешно запуститься и даже не выдать видимых ошибок при первом старте. Программист радостно сдает работу клиенту, но спустя недели или месяцы начинают всплывать «тихие ошибки»:
Если ручное последовательное обновление через цепочку релизов занимает слишком много времени, необходимо использовать инструменты автоматизации и правильные параметры запуска системы.
Для минимизации рутинного труда рекомендуется использовать специализированные решения, например Обновлятор-1С. Эта программа самостоятельно:
Для сокращения времени ожидания выполнения фоновых обработчиков при клиент-серверном варианте работы базы, мы можем использовать специальный параметр запуска платформы /C ВыполнитьОтложенноеОбновлениеСейчас. Этот ключ заставляет БСП выполнять отложенные обработчики в монопольном режиме на максимальной скорости, не растягивая процесс во времени.
Пример запуска базы из командной строки для форсирования выполнения обновлений:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F"C:\1C_Bases\Accounting" /N"Администратор" /P"Пароль" /C ВыполнитьОтложенноеОбновлениеСейчас /UpdateDBCfg
Подводя итог, ответим на вопрос автора темы: делать обновление через загрузку финального cf на старую базу категорически нельзя. Данный метод гарантирует появление скрытых ошибок и потерю данных. Единственный надежный способ — строгое следование рекомендованной цепочке обновлений с обязательным запуском режима «Предприятие» на ключевых релизах конфигурации.