Зачем нужна возможность делать резервную копию базы после каждого промежуточного обновления?

оглавлениеКак отключить предупреждение об антивирусе?

Обновлятор-1с. Расскажите о схеме обновления множества однотипных и изменённых баз, которые не обновляются автоматически.

Статья устарела и требует переработки?

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

У него 100 однотипных типовых баз 1С:Бухгалтерия 2.0. Причём в код конфигураций внесены изменения, которые сломали автоматическое обновление (как в 1С, так и в обновляторе). Это вызвано тем, что 1С (и соответственно обновлятор) не может в полностью автоматическом (пакетном) режиме применять новые обновления к базе, так как у неё возникают конфликты с изменениями (пусть и небольшими), внесенными в базу.

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

Мы с ним разработали такое решение этого вопроса.

Одну из этих 100 баз (имеющих одинаковые, пусть и доработанные конфигурации) мы отметили для себя как "Эталонная база".

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

После того как эталонная база обновлена (предположим на обновление версии 2.0.3.64) и он убедился, что всё ок, клиент создаёт копию этой базы, полностью снимает её (копию!) с поддержки и выгружает конфигурацию базы (через конфигуратор) во внешний файл с именем load.cf.

Далее он копирует этот файл в папку с обновлением 2.0.3.64 в шаблонах 1С.

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

Для этого (один раз и навсегда) он снимает все 99 баз с поддержки (и только их, эталонная всегда будет оставаться на поддержке) и в расширенных свойствах этих 99 баз в обновляторе устанавливает вот эту галку:

Запускает обновление этих 99 баз через обновлятор и вуаля! :)

Обновлятор-1С в этом случае определит для этих баз, что следующим обновлением является обновление версии 2.0.3.64, в этом обновлении он увидит файл "load.cf", загрузит этот файл в каждую из баз и выполнит все необходимые регламентные процедуры.

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

Зачем мы сделали копию эталонной базы и сняли её (копию) с поддержки перед тем как выгружать файл конфигурации? Если бы мы этого не сделали, то после обновления все 99 баз снова бы встали на поддержку и нам пришлось бы снимать её для следующего обновления.

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

С уважением, (школа 1С программистов).

Подписывайтесь и получайте новые статьи и обработки на почту (не чаще 1 раза в неделю).

Вступайте в мою группу ВКонтакте, Одноклассниках, Facebook или Google+ — самые последние обработки, исправления ошибок в 1С, всё выкладываю там в первую очередь.

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



Зачем нужна возможность делать резервную копию базы после каждого промежуточного обновления?

оглавлениеКак отключить предупреждение об антивирусе?