Как обновить несколько баз 1с одновременно

Обновлено: 07.07.2024

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

Хранилище конфигураций 1С по своей сути является системой контроля версий. Главным удобством хранилища для обновления баз является возможность пакетного запуска 1С и обновления конфигурации из этого хранилища. Как это выглядит на деле: для каждой поддерживаемой конфигурации создается хранилище. Эти хранилища обновляются штатными методами по факту выхода новых релизов от поставщиков. Чтобы обновить "боевую" базу 1С из этого хранилища требуется последовательно запустить 1С в режиме конфигуратора с ключами

1) ConfigurationRepositoryF(" Путь к хранилищу ") /ConfigurationRepositoryN(" Пользователь хранилища ") /ConfigurationRepositoryP(" Пароль пользователя хранилища ") /ConfigurationRepositoryUpdateCfg

эта команда выполняет подключение к хранилищу и обновление текущей конфигурации из него.

эта команда выполняет обновление конфигурации базы данных. Тут нужно понимать, что системе наверняка потребуется изменять структуру таблиц БД, поэтому доступ должен быть монопольным. Как этого добиться? Все теми же ключами запуска

1) /CЗавершитьРаботуПользователей - для того, чтобы отключить всех пользователей (тут присутствуют известные проблемы с модальными окнами и запросами на выход из системы)

2) /CРазрешитьРаботуПользователей /UCКодРазрешения - для разрешения работы.

ВАЖНО! Если используется запрет на работу пользователей, то при обновлении базы необходимо добавлять ключ /UCКодРазрешения.

Итого, для обновления мы получаем всего 4 последовательных операции:

ENTERPISE /F"Путь" /N"Юзер" /P"Пароль" /CЗавершитьРаботуПользователей

DESIGNER /F"Путь" /N"Юзер" /P"Пароль" /ConfigurationRepositoryF" Путь к хранилищу " /ConfigurationRepositoryN" Пользователь хранилища " /ConfigurationRepositoryP" Пароль пользователя хранилища " /ConfigurationRepositoryUpdateCfg /UCКодРазрешения

DESIGNER /F"Путь" /N"Юзер" /P"Пароль" /UpdateDBCfg /UCКодРазрешения

ENTERPISE /F"Путь" /N"Юзер" /P"Пароль" /CРазрешитьРаботуПользователей /UCКодРазрешения

Загоняем в цикл по своим базам и радуемся жизни.

Казалось бы все элементарно, но существует ряд ошибок, которые, судя по форумам, встречаются довольно часто.

Пытаемся завершить/разрешить работу пользователей в режиме конфигуратора
Пытаемся обновить конфигурацию, к которой запрещен доступ, не используя /UCКодРазрешения
Забываем, что лучший штатный механизм для получения монопольного режима - телефон

Конечно, статья не станет откровением для гуру, но новичкам вполне может пригодиться.

UPD: Типовая БП 2.0.12.2 обновляется до 2.0.42.6 за 6.5 минут (замер производился без данных в базе)

Давайте представим, что у нас на обслуживании 100 баз, имеющих одну и ту же доработанную конфигурацию.

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

Как обновлять эти 100 баз?

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

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

Именно этот вариант мы рассмотрим ниже.

Схема

Подготавливаем load.cf

Одну из этих 100 баз отмечаем для себя как "Эталонная база".

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

выгружаем конфигурацию базы (через конфигуратор) во внешний файл с именем load.cf.

Готовим оставшиеся 99 баз к обновлению

Заходим в свойства каждой из этих баз на закладку "Обновление".

И устанавливаем опцию "Я подготовил уже обновлённый и доработанный файл конфигурации с именем load.cf и положил в соответствующую папку обновления, нужно просто загрузить его в базу":

Мы можем установить эту опцию сразу во всех выбранных базах вот так.

Копируем load.cf в нужное место

Теперь нам нужно скопировать подготовленный load.cf в место, откуда его подхватят оставшиеся 99 баз при обновлении.

Тут возможно несколько вариантов.

Первый вариант

создать пустую папку
положить в неё load.cf
прописать (обязательно) эту папку в качестве источника обновлений в свойствах базы

Второй вариант

Но что если нам нужно выстроить цепочку из load.cf.

Или мы хотим настроить всё так, чтобы повторный запуск обновления не подхватывал уже примененный к базе load.cf (а именно так будет происходить в первом варианте, пока мы не удалим load.cf или не очистим папку для поиска обновлений в свойствах баз).

В этом случае нам достаточно положить файл load.cf в папку с очередным полноценным обновлением, которое было бы применено к базам при обычном поиске обновлятором.

Например, наша конфигурация имеет версию 1.0.0.0 Мы хотим обновить её последовательно сначала на 1.0.0.1, а затем на 1.0.0.2:

подготавливаем два load.cf (один для версии 1.0.0.1, а другой для версии 1.0.0.2)
скачиваем и распаковываем в шаблоны обновления для 1.0.0.1 и 1.0.0.2 (то есть это должны быть полноценные обновления с такими файлами как 1cv8.cfu, 1cv8.mft и UpdInfo.txt).
кладём каждый load.cf в папку с соответствующим ему обновлением

Поехали

Готово, запускаем обновление оставшихся 99 баз в обновляторе.

сам подхватит нужные load.cf
загрузит их в базу
выполнит обновление базы данных
выполнит обработчики обновления

Ответы на дополнительные вопросы

В: "А что если у меня есть несколько уникальных баз и мне нужно применить к ним цепочку уникальных для каждой базы load.cf?"

О: "В этом случае подготовьте цепочку load.cf для каждой из баз. Далее создайте отдельный комплект распакованных обновлений (второй вариант) для каждой из баз и поместите эти load.cf в соответствующие папки. Далее пропишите каждый комплект обновлений (корневую папку) в свойствах соответствующей ему базы в качестве папки для поиска обновлений."

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

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

Это как русская рулетка. Может пройдет без проблем, а может и с проблемами.

(0) сталкивался на двух конфигурациях (УНФ и ТСЖ), что лучше всего после каждого обновления на релиз запускать в режиме Предприятие, т.к. могут поднапакостить пресловутые обработки обновления
В типовых от 1с обычно проблем нет. С отраслевыми не знаю.
(0)
Думаешь в сильно изменной конфе хоть кто накатывает релизы последовательно ?
Хотел бы на такого посмотреть
А ошибки вручную напильничком
(8) В шапке ни слова про конфу, следовательно речь идет о сферической конфигурации в вакууме.
(0) кто-нибудь может объяснить зачем это делать, кроме как из-за лени? А потом мучиться и переделывать разве легче и быстрее?
Я б таких обновляторов и близко к базе не подпускал

(14)
Потому что обновление занимат от недели до месяца.

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

То обновляют на старых платформах, то сразу на последний релиз скачут, а потом "спасите тут какие-то ошибки".
Извините, накипело.
у меня эта метода не сработала например при обновлении сельхозки, а с типовыми вроде все норм
хотя обычно я так не делаю
(16) одна реструктуризация идет неделю?
Ну это точно не проблема обновления. Может прежде чем обновлять это сначала решить?
(0) я против шагать через релизы.
Обновляться надо через cfu и каждый раз запускать предприятие и давать ей обработать данные.
(19) ну например, с ут 11.1 на Ут 11.3. Конфы практически одинаковые, а между ниму 80 релизов. Как вы поступите?
(19)
Вы действительно не можете представить баз где обновление неделю ? )))
причем здесь реструктуризация, прекратите свои фантазии
(0) Нет не работает.
Обновляли ерп с 2.1 на 2.2 там последовательно релиза 3-4 надо было. делали эксперимент 1 пропускали, выяснили одну из причин - в том релизе который пропустили есть функция в модуле менеджера, а в след ее уже нет и задания с пред релиза выдавали ошибку. Это как пример.

(0) Можно, если говорим про типовые или созданные на их основе.

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

(14) Угу, база не обновлялась с 2012 года, то есть пять лет. С релиза 1.17.х до 2.10.х. Это 12 промежуточных с глобальным переходом с ред.1 на ред.2. Доработок за пять лет наделали - конфа перелопачна так, что создатели не узнают. Переносить все в каждый из релизов - это недели две как минимум на один релиз. Надо было полгода заниматься обновлением? В итоге скачок через 12 релизов был сделан за три недели, уже полгода сидят на последнем релизе и радуются. А чтобы ошибок не было надо просто голову иметь.

(20) В типовых фирма 1с так не делает, она сначала накатывает последний релиз, а потом уже запускает режим предприятия. Наверное в 1С дураки сидят, раз заложили такой механизм
(21) 11.1 и 11.3 - одинаковые? Хорошая шутка, особенно оценят те, кто много изменений внес.

Есть Справочник1 с реквизитом Реквизит1.
В какой-то момент крутые ребята из 1с подумали что реквизит этот больше не нужен и обозвали его Удалить_Реквизит1. А данные из него перельются в новенький Реквизит2 обработчиком, который запустится после обновления.
И все будет ок, ведь мы обновляемся с cfu
А потом в релизе Х, ребятки и вовсе удалят реквизит Удалить_Реквизит1

Накатив cf, мы гарантированно потеряли данные: Реквизит2 пустой, а реквизит Удалить_Реквизит1 удален.

Это как русская рулетка. Может пройдет без проблем, а может и с проблемами.

(14)
Потому что обновление занимат от недели до месяца.

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

(0) Можно, если говорим про типовые или созданные на их основе.

Накатив cf, мы гарантированно потеряли данные: Реквизит2 пустой, а реквизит Удалить_Реквизит1 удален.

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