В 1с запустили автоматическое обновление программы как это повлияет на работу

Обновлено: 06.07.2024


без конкретики - это разговоры про погоду. Что за конфа, что там происходит в обновлении версии - хрен знает. Обновление версии - это не волшебная ни какая палка, а просто код, который написали 1сники из мяса и костей. Позаботились они об откате, значит откатится. Не позаботились - не откатится. Что случится при повторном запуске - да хрен знает. Но обычно обновление версии, типовое по крайней мере, пишут так, чтобы оно откатывалось и воспроизводилось. Обычно.
+2 на последних релизах отмутили они там с Производственным календарем.
(0) да, отработает корректно, т.к. делается всё обновление в транзакции

(0) >> 1С откатит на то состояние, которое было до запуска этого Обновления?

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

>> И после того как . заново запустить, то второй заход Обновление версии программы отработает корректно?

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

Если версия уже обновилась, можешь вручную в регистре написать старый номер версии. В таком случае обработчики запустятся повторно.

Принудительно запустить обновление можно обработкой ИнструментыРазработчикаОбновлениеВерсииИБ.epf из комплекта инструментов разработчика той версии БСП, которая включена в вашу конфигурацию. Версию БСП, включенной в вашу конфигурацию, можно посмотреть в том же регистре ВерсииПдсистем (строка СтандартныеПодсистемы).

(5) >> делается всё обновление в транзакции

С какого перепугу? А отложенные обработчики обновления (выполняемые в фоне после основного обновления) в одной транзакции - это вообще супер!

Разработчики 1С предоставили пользователям возможность самостоятельно проводить обновление информационных баз в режиме 1С: Предприятие. Однако, эта процедура является для пользователя черным ящиком, иногда процесс зацикливается и приводит к зависанию.

Прождав несколько часов или суток (в зависимости от терпения) пользователь принудительно снимает задачу и после повторного запуска получает невосстановимую ошибку базы данных.

Как происходит автообновление

О необходимости обновления нас уведомляет монитор ИТС, который периодически выскакивает при запуске программы.

Что нужно обновлять?

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

Обычно в месяц выходит 3-4 релиза конфигурации. Каждое новое обновление обновляет 5-6 предыдущих релизов, поэтому при обновлении можно перескочить через несколько релизов.

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

После нажатия кнопки "Установить обновление" мы имеем возможность выбрать что именно хотим обновить и после этого опускается занавес.

Что в черном ящике?

В теории, в этот момент происходит следующее:

  1. Программа создает резервную копию базы;
  2. Происходит загрузка файлов обновления конфигурации и платформы;
  3. Далее идет установка новой платформы;
  4. Устанавливается конфигурация базы данных;
  5. После установки новой конфигурации идут служебные обработки, которые трансформируют данные под новую конфигурацию;
  6. Устанавливаются патчи.

Если пропущено много релизов, пункты 4-6 повторяются.

Почему обновление 1С может зависнуть?

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

  • Резервное копирование не может завершиться успешно.

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

  • Новая версия платформы не может установиться.

Причиной чаще всего является отсутствие прав администратора на локальном компьютере. Стоит обратиться к системному администратору.

  • Пропущено много релизов или очень большая база данных или очень медленный компьютер.

В этом случае автообновление идет, но очень-очень медленно. Имеет смысл провести обновление на более быстрой машине и модернизировать компьютер. О том, как ускорить работу компьютера, я писал здесь .

  • Патчи, установленные для предыдущего релиза мешают установке нового.

В этом случае, придется сперва удалить установленные патчи, а потом устанавливать новый релиз.

Для того, чтобы избежать всех этих ошибок и точно знать, что происходит с вашей базой данных, необходимо проводить обновление в ручном режиме. Это не сложно, зато весь процесс будет под Вашим контролем.

В свойствах баз обновлятора (в версиях после 3 ноября 2017 года) появилась вот такая замечательная опция:

Сразу оговорюсь, что работать эта возможность будет только с платформой 1С равной или старше 8.3.8.1652. Именно начиная с этой версии 1С позволяет выполнять обновление доработанных конфигураций в пакетном режиме.

Когда она может быть полезна

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

При этом все дописки вы знаете и они у вас задокументированы.

В таком случае может быть проще и быстрее:

  1. Сначала обновить конфигурацию обновлятором (установив соотв. галку в свойствах базы)
  2. Затем посмотреть отчёт обновления в обновляторе (там будут указаны свойства,измененные дважды)
  3. И только после этого проверить, что все доработки на месте и вернуть те, что были утеряны (об этом смотрите ниже, где я рассказываю как работает автоматическое обновление доработанных конфигураций)

При таком способе работы вам не нужно:

  1. Скачивать необходимые обновления
  2. Открывать конфигуратор и применять эти обновления
  3. Ожидать пока выполнится обновление конфигурации
  4. Ожидать пока выполнится обновление базы данных

Вы вообще можете запланировать такое обновление на ночь, а уже утром произвести контроль и доработку, если она потребуется.

И если доработки конфигурации небольшие, то в большинстве случаев вам после обновления вообще не придётся ничего делать.

Ваше вмешательство будет нужно тогда, когда в обновлении будет изменен тот же самый объект, что изменен у вас (это и называется "измененные дважды"). И вы можете легко находить такие объекты, просматривая отчёт обновлятора:


Как работает автоматическое обновление доработанных конфигураций

Само обновление происходит при помощи того же пакетного ключика updatecfg, но при этом обновлятор дополняет эту команду специальным файлом настроек в формате xml.

Обновление происходит с приоритетом новой конфигурации, при этом:

  1. Если вы добавляли в конфигурацию новый объект - обновление его не затронет.
  2. Если вы добавляли в конфигурацию новый реквизит в уже существующий объект типовой (от поставщика) - обновление его также не затронет.
  3. Если вы меняли в конфигурации объект поставщика, но он не изменился в этом обновлении, то он останется как есть.
  4. Но, если вы меняли в конфигурации объект поставщика, и он изменился в этом обновлении, то возьмётся версия из обновления. При этом в отчёте обновлятора этот объект будет отмечен как "дважды измененный".

При этом, при настройке по умолчанию.

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

Я очень надеюсь, что эта возможность позволит высвободить ещё немного часов от ручного, монотонного труда.

Как настроить финальное объединение с эталонной конфигурацией

Чтобы стало понятнее о чём речь, приведу рабочий пример у одного из пользователей обновлятора.

У него 40 бухгалтерских баз. Все они содержат одну и ту же доработанную конфигурацию.

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

Алгоритм работы до автоматизации у него был такой:

"В ручном режиме обновляю до последнего релиза одну базу; в последнем релизе тестирую, добавляю все изменения, которые были потеряны, в модулях форм документов, общих модулях. Затем обновляю остальные базы до последнего релиза и в конце объединяю с подготовленным cf файлом из первой базы."

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

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

И я доработал эту возможность.

Чтобы заставить обновлятор после применения обновления следом выполнить ещё и объединение с конфигурацией из файла - необходимо расположить файл с конфигурацией для объединения в папку обновления под именем MergeThisFileAfterUpdate.cf

В рассмотренном выше примере предположим, что требуется обновить все 40 конфигураций на следующие релизы (и пусть они для упрощения задачи будут ключевыми, то есть их нельзя перескакивать): 2.0.60.1, 2.0.60.2 и 2.0.60.3.

Алгоритм наших действий с учётом автоматизации обновлятором будет следующим:

  1. Обновить при помощи обновлятора одну из конфигураций до версии 2.0.60.3
  2. Добавить все изменения, которые были потеряны. проверить работоспособность обновлённой конфигурации.
  3. Выгрузить эту конфигурацию в папку с обновлением 2.0.60.3 под именем MergeThisFileAfterUpdate.cf
  4. Запустить обновление (с включенной возможностью обновления доработанных конфигураций) оставшихся 39 баз.
  5. Обновлятор в этом случае для каждой из 39 баз:
    1. выполнит пакетное обновление на 2.0.60.1
    2. выполнит обработчики обновления
    3. выполнит пакетное обновление на 2.0.60.2
    4. выполнит обработчики обновления
    5. выполнит пакетное обновление на 2.0.60.3
    6. обнаружит, что в папке с обновлением 2.0.60.3 лежит файл MergeThisFileAfterUpdate.cf
    7. выполнит пакетное объединение нашей конфигурации с конфигурацией из файла MergeThisFileAfterUpdate.cf (о настройках такого объединения смотрите ниже)
    8. выполнит обработчики обновления

    При этом пакетное объединение выполняется через пакетный ключик конфигуратора mergecfg и следующий файл настроек (передаётся через ключ settings):

    Такие настройки объединения позволяют нам привести нашу конфигурацию (которая всё ещё на поддержке) к конфигурации в файле MergeThisFileAfterUpdate.cf, в которую мы внесли и исправили все наши доработки.

    Объединение с эталонной конфигурацией как отдельная операция

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

    Эта возможность доступна на закладке "Скрипты" в главном окне программы.

    Тип скрипта "Пакетный". Из меню следует выбрать пункт "Обновлятор"->"Методы"->"Объединить с конфигурацией из файла":

    В скрипт вставится вот такой текст:

    Путь к файлу, с которым нужно выполнить автоматическое объединение, у вас, конечно, будет свой.

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

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

    Вторую команду можно вставить в скрипт из меню шаблонов:

    С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).

    Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.

    Суть рассматриваемого вопроса изложена в заголовке, повествование разобьем на три части. Отдельно внизу будут приведены тексты скриптов.

    1) Предисловие

    Вопрос необходимости резервного копирования в автоматическом режиме не подлежит сомнению ни у корифеев, ни у новичков. В статье рассмотрим резервное копирование средствами 1С (что имеет ряд преимуществ перед копированием средствами СУБД). При этом будут применены средства пакетного запуска платформы 1С, powershell и планировщик задач Windows.

    Задачи обновления информационных давно автоматизированы, но только для типовых конфигураций, либо тех, что используют библиотеку стандартных подсистем. В моем случае мы работаем со старенькой Альфа-Авто редакции 4, которая распространяется на 12 серверов. Изменения вносятся примерно два раза в неделю, поэтому выгода от автоматизации налицо.

    В обоих случаях мы имеем следующие исходные данные:

    • Операционная система Windows Server (версии от 2008 до 2012);
    • Клиент-серверный вариант платформы 1С 8.3 (с обязательно установленным компонентом COM-соединение).

    2) Резервное копирование

    После прочтения указанных ссылок мы уже знаем, что надо сделать, чтобы запустить скрипт powershell, поэтому сразу перейду к делу.

    Сделать резервную копию информационной базы в пакетном режиме очень просто, надо только «выгнать» всех пользователей. Делать мы это будем, подключившись COM-объектом к базе данных. Это в нашем примере делает функция ExitAll. В тело функции зашито, что она вызывается на том сервере, на котором, собственно, установлен кластер серверов 1С. Вызовите эту функция безо всяких параметров в своем скрипте на сервере — и ВСЕ пользователи из ВСЕХ баз кластера вылетят.

    Приношу свои извинения человеку, чьим кодом я воспользовался при написании этой процедуры — авторство восстановить не удалось.

    После этого следует вызвать функцию BackUpBase с параметром — имя информационной базы. У меня во всех ИБ есть служебный администратор с одинаковыми учетными данными, поэтому я их просто захардкодил. При необходимости можно их параметризовать, либо обойтись аутентификацией ОС.

    Итоговый скрипт сохраняем в файл.

    В планировщике задач создаем «Простую задачу», имя, разумеется, на ваше усмотрение.
    У меня работает ежедневно, но и тут хозяин — барин. Запускать лучше всего ночью, когда никто не работает, например, в 3:00. Действие для задачи — «Запустить программу». Сама программа у нас «powershell.exe». А вот ее аргументы —


    где ExitAllUsersAndBackup.ps1 — как раз наш сохраненный скрипт.
    -ExecutionPolicy RemoteSigned — ключ, который разрешает выполнение пакетных скриптов powershell, если в системе они глобально не разрешены. Работает через раз (возможно, не хватает компетенции чтобы разобраться, но закономерности не нашёл). В случаях, когда не работает с этим ключом, приходится разрешать выполнение скриптов для всего сервера.

    Для этого Win+R, powershell.exe,


    и подтверждаем действие.

    Время работы с данными скриптами — более трех месяцев. Перебои были, но связаны с отключением электричества и прочими внешними факторами.

    3) Обновление конфигурации

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

    Конфигурацию мы храним на ftp-сервере, на который помещаем ее вручную. Файл конфигурации называется GK.cf, в приведенном примере обновляется одна единственная конфигурация. Потенциально можно так же обновлять и несколько различных конфигураций.
    На ftp рядом с GK.cf помещаем файл с названием flag.txt. Наличие этого файла сигнализирует о том, что обновляться надо. Можно проверять наличие самого фйла GK.cf, но мы используем флаг так же для других целей.

    Скрипт работает следующим образом:

    • Удаляет GK.cf и flag.txt, если таковые есть в рабочем каталоге (у пользователя, от имени которого будет запускаться планировщик, должно быть право на запись в этот каталог);
    • Предпринимается попытка скачать файл флага;
    • Если такой файл скачать получилось — скачиваем .cf;
    • Собственно, обновление функцией UpdateCf.

    Надежность этого скрипта чуть меньше. Обновление проходит до конца на 100% в тех случаях, когда меняется структура метаданных. В других случаях бывает, как я предупреждал ранее, появление активного пользователя. В результате конфигурация загружена в базу, но конфигурация базы данных не обновлена (снова прошу прощения за подобную кривоватую терминологию перед людьми, не связанными с 1С). В остальном — полет нормальный.

    Читайте также: