При обновлении типовых и доработанных конфигураций на платформе «1С:Предприятие 8.3» специалисты часто сталкиваются с неприятной ситуацией. В Конфигураторе процесс обновления файлов (CF или CFU) проходит успешно и без предупреждений. Однако при последующем запуске базы данных в режиме «1С:Предприятие» система аварийно завершает работу, выдавая сообщение следующего вида:
«Техническая информация об ошибке записана в журнал регистрации. Обновление на текущую версию допустимо только с версии 11.4.7 и выше (Недопустимая попытка обновления с версии 11.4.6.188)...»
В этой статье мы подробно разберем, почему возникает данная ошибка, как устроен механизм проверки версий в Библиотеке стандартных подсистем (БСП), и какими способами можно решить эту проблему без потери данных.
Для того чтобы понять природу этой ошибки, проанализируем разницу между обновлением конфигурации и обновлением информационной базы (ИБ). Этот процесс состоит из двух принципиально разных этапов:
Рассмотрим классический пример, почему нельзя «перепрыгивать» через релизы в режиме Предприятия:
Номенклатура.Цена).ЦеныНоменклатуры. В самом справочнике реквизит переименовали в УдалитьЦена. При первом запуске релиза №2 в режиме Предприятия срабатывает обработчик обновления, который берет значения из УдалитьЦена и записывает их в регистр сведений.УдалитьЦена полностью удаляется из метаданных за ненадобностью.Что произойдет, если мы обновим конфигурацию в Конфигураторе сразу с релиза №1 на релиз №3, минуя запуск Предприятия на релизе №2? Таблица базы данных лишится поля цены еще до того, как программный код успеет перенести эти данные в регистр сведений. В итоге вся история цен будет безвозвратно утеряна. Чтобы не допустить таких критических потерь, разработчики БСП внедрили жесткую проверку номеров версий.
Информация о текущей версии структуры данных хранится в специальном служебном регистре сведений ВерсииПодсистем. При запуске Предприятия система считывает текущую версию конфигурации и сравнивает ее с версией из регистра. Если обнаруживается критический разрыв (например, база имеет структуру данных версии 11.4.6, а конфигурация требует строго версию не ниже 11.4.7), БСП блокирует запуск и выводит ошибку.
Если вы обновляете рабочую базу данных, этот метод является единственно верным. Ни в коем случае нельзя пытаться обойти проверку программными методами, так как это гарантированно приведет к нарушению ссылочной целостности и потере данных.
Разберем по шагам правильный алгоритм последовательного обновления:
Бывают ситуации, когда база является тестовой, демонстрационной или абсолютно новой, и сохранность старых тестовых данных для вас не имеет никакого значения. Тратить несколько часов на последовательное обновление такой базы нецелесообразно. В этом случае проверку версии БСП можно обойти.
Проанализируем программный код, отвечающий за эту блокировку. Проверка возможности обновления выполняется в общем модуле БСП. Чтобы обойти ее, выполним следующие действия:
ОбновлениеИнформационнойБазыКлиентПереопределяемый или аналогичный ему (в зависимости от версии БСП название может немного отличаться, например, проверка может располагаться в модуле ОбщегоНазначенияУТКлиент).ПриОпределенииВозможностиОбновления. В ней происходит анализ структуры метаданных и записей регистра ВерсииПодсистем.
Процедура ПриОпределенииВозможностиОбновления(Параметры) Экспорт
Возврат; // Временный обход проверки БСП
// Оригинальный код процедуры...
КонецПроцедуры
После этого сохраните конфигурацию базы данных и запустите режим Предприятия. Система пропустит шаг проверки версий. Важно: после успешного запуска базы не забудьте удалить эту строчку кода или отключить расширение, чтобы вернуть типовой функционал безопасности на место.
Если база данных «зависла» в промежуточном состоянии, резервной копии под рукой нет, а запустить Предприятие необходимо, можно прибегнуть к искусственному изменению номера версии непосредственно в базе данных. Для этого нам потребуется скорректировать данные в служебном регистре.
Рассмотрим детально этот процесс:
ВерсииПодсистем напрямую. Для этого можно воспользоваться внешней обработкой по чтению/записи наборов записей регистров, либо запустить систему в режиме отладки с пропуском кода ошибки.ВерсииПодсистем найдите строку, соответствующую основной конфигурации. Обычно в поле «Имя подсистемы» указано УправлениеТорговлей (или имя вашей отраслевой конфигурации).11.4.6.188.11.4.7.1.После этой манипуляции БСП при запуске будет «думать», что база данных уже успешно прошла этап конвертации данных версии 11.4.7, и позволит запустить финальные обработчики для релиза 11.4.9.70.
Внимание! Этот метод является экстремальным. Используя его, вы берете на себя полную ответственность за возможную несогласованность данных. Если в версии 11.4.7 были важные обработчики, переносящие информацию между регистрами, эти данные не перенесутся, что может повлечь за собой ошибки в отчетах по продажам, взаиморасчетам или складским остаткам.
Если вам приходится регулярно обслуживать большое количество баз данных 1С, которые редко обновляются, последовательный запуск десятков релизов вручную превращается в рутину. Для решения этой проблемы рекомендуется использовать специализированное программное обеспечение для автоматизации обновлений (например, утилиту «Обновлятор-1С» или аналогичные скрипты автоматизации).
Такой софт умеет самостоятельно определять цепочку необходимых релизов, скачивать их с портала техподдержки 1С, последовательно применять файлы обновлений в Конфигураторе, автоматически запускать сеанс Предприятия, контролировать завершение работы фоновых заданий БСП и переходить к следующему шагу без участия системного администратора.