Обновить конфигурацию 1С динамически: когда можно и чем грозит

Динамическое обновление конфигурации 1С — это применение изменённой конфигурации к базе, пока в ней работают пользователи, без монопольного режима. Новые сеансы сразу получают новую версию, а уже открытые продолжают работать со старой до перезапуска.

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

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

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

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

• 🔹 новые сеансы стартуют уже с обновлённой конфигурацией;
• 🔹 открытые сеансы продолжают работать со «старым поколением» конфигурации;
• 🔹 пользователь увидит изменения только после перезапуска клиента.

Получается, что какое-то время в одной базе одновременно живут две версии прикладной логики. Отсюда и все риски.

Проверить из кода, что конфигурация изменилась после запуска сеанса, можно функцией глобального контекста КонфигурацияБазыДанныхИзмененаДинамически(). Типовые конфигурации на БСП делают это сами: периодически проверяют и предлагают пользователю перезапустить программу.

Если КонфигурацияБазыДанныхИзмененаДинамически() Тогда
    ПоказатьПредупреждение(, "Программа обновлена. Перезапустите её, чтобы получить изменения.");
КонецЕсли;

Когда динамическое обновление уместно, а когда нет

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

Уместно обновлять динамически:

• ✅ мелкие правки кода и форм в рабочее время, когда ошибка мешает людям прямо сейчас;
• ✅ срочное исправление печатной формы или отчёта;
• ✅ правки в обработках, которые запускают несколько человек.

Не стоит, даже если платформа разрешает:

• ⛔ если меняется логика проведения документов, а пользователи сейчас проводят документы;
• ⛔ если меняются правила обмена или регламентные задания, которые работают в фоне;
• ⛔ если исправление затрагивает расчёт, где старый и новый код дадут разные суммы.

Чем рискуете: ограничения и подводные камни

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

Две версии логики одновременно

Бухгалтер, не перезапустивший 1С, проводит документ по старому алгоритму. Его коллега после перезапуска — по новому. Через неделю при сверке выясняется, что половина документов за день посчитана иначе. Найти, какие именно, бывает непросто.

Фоновые задания и сеансы сервера

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

Ошибки у пользователей после обновления

Открытые формы, которые изменились, могут вести себя непредсказуемо: ссылка на удалённую процедуру или изменённый параметр общего модуля приводят к ошибкам выполнения у «старых» сеансов. Лечится перезапуском клиента.

Поддержка поставщика

Если типовая конфигурация на поддержке, правки и так усложняют будущие обновления. Динамическое применение этого не меняет, но соблазняет вносить мелкие правки «на живую» без учёта и описания. Через полгода никто не помнит, что меняли.

Как обновить конфигурацию динамически: пошагово

Порядок для файловой и клиент-серверной базы одинаковый.

Шаг 1. Сделайте резервную копию

Даже правка кода может пойти не так. Минимум — сохраните текущую конфигурацию базы данных в файл: Конфигурация → Сохранить конфигурацию в файл… (получится .cf). Для полноценной страховки сделайте копию всей базы (см. раздел о выгрузке ниже).

Шаг 2. Внесите и проверьте изменения

1. Откройте базу в Конфигураторе: 1cv8.exe DESIGNER или кнопкой «Конфигуратор» в окне запуска.
2. Откройте конфигурацию: Конфигурация → Открыть конфигурацию.
3. Внесите правки.
4. Запустите синтаксический контроль модулей: Конфигурация → Проверка конфигурации…, либо хотя бы Ctrl+F7 внутри изменённого модуля.

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

Шаг 3. Запустите обновление

1. Нажмите F7 или выберите Конфигурация → Обновить конфигурацию базы данных.
2. Если пользователи работают, платформа сообщит, что не удалось установить монопольный режим, и предложит выполнить динамическое обновление.
3. Подтвердите. При наличии изменений структуры платформа откажет — тогда остаётся только монопольный режим или фоновое обновление.
4. Платформа покажет список изменённых объектов. Просмотрите его: если там неожиданно оказался реквизит или новый объект, значит, правка требует реструктуризации.

Шаг 4. Сообщите пользователям

Разошлите короткое сообщение: «Обновили печатную форму счёта, перезапустите 1С». Без перезапуска люди продолжат работать со старым кодом и решат, что исправление не помогло.

Если платформа отказывает в динамическом обновлении

Отказ почти всегда означает, что в списке изменений есть структурные правки. Частые неочевидные причины:

• 🔸 добавили реквизит «на будущее» и забыли о нём;
• 🔸 изменили длину строки или точность числа у существующего реквизита;
• 🔸 добавили индексирование реквизита — это тоже меняет структуру таблицы;
• 🔸 сравнили и объединили конфигурацию с файлом, и вместе с нужным модулем приехали лишние объекты.

Что делать: откройте сравнение основной конфигурации с конфигурацией базы данных (Конфигурация → Сравнить конфигурации…) и посмотрите, что ещё отличается. Если лишнее попало случайно, верните эти объекты к состоянию конфигурации базы данных и повторите F7. Если структурная правка нужна, переносите обновление в окно обслуживания или используйте фоновое обновление.

Если отказ приходит даже на правке одного модуля, проверьте, ту ли базу вы обновляете. В пакетном режиме легко перепутать путь после /F или имя базы после /S и применить изменения не туда.

Динамическое обновление из командной строки

Для скриптов и планировщика пригодится пакетный режим Конфигуратора. Ключ /UpdateDBCfg обновляет конфигурацию базы данных, а параметр -Dynamic управляет динамическим режимом:

• -Dynamic+ — разрешить динамическое обновление;
• -Dynamic- — запретить его (обновление пройдёт только в монопольном режиме).

Пример для клиент-серверной базы:

"C:\Program Files\1cv8\8.3.24.1342\bin\1cv8.exe" DESIGNER /S "srv1c\buh" /N "Администратор" /P "пароль" /UpdateDBCfg -Dynamic+ /Out "C:\logs\update.log"

Для файловой базы вместо /S указывается /F "D:\Bases\Buh". Номер платформы в пути подставьте свой: каталог bin лежит в папке установленной версии внутри C:\Program Files\1cv8\ (для 32-битной платформы — C:\Program Files (x86)\1cv8\).

После запуска откройте лог. Если в нём есть сообщение об успешном обновлении — всё прошло. Если обновление требовало реструктуризации, а стоял ключ -Dynamic- или пользователи не вышли, в логе будет причина отказа. Скрипт должен проверять код возврата 1cv8.exe и лог, а не считать каждый запуск успешным.

Резервная копия перед обновлением: выгрузка в .dt

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

Где взять исполняемый файл

Выгрузку делает тот же 1cv8.exe, отдельной утилиты не нужно. Он лежит в каталоге конкретной версии платформы:

Если установлено несколько версий, используйте ту, на которой работает база. Узнать её можно в окне Справка → О программе в режиме 1С:Предприятие.

Выгрузка через интерфейс

1. Откройте базу в Конфигураторе.
2. Выберите Администрирование → Выгрузить информационную базу….
3. Укажите папку и имя файла, например buh_2026-10-07.dt, и дождитесь сообщения о завершении.

Выгрузка из командной строки

"C:\Program Files\1cv8\8.3.24.1342\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh" /N "Администратор" /P "пароль" /DumpIB "E:\Backup\buh.dt" /Out "E:\Backup\dump.log"

Для больших SQL-баз быстрее и надёжнее резервная копия средствами СУБД (MS SQL, PostgreSQL). Выгрузку .dt на базе в десятки гигабайт лучше запускать вне рабочего времени: она идёт долго и нагружает сервер.

Альтернативы: если динамически нельзя

Монопольное обновление в окно обслуживания

Классический путь. Установите блокировку сеансов (в типовых конфигурациях — в разделе Администрирование → Обслуживание), дождитесь выхода пользователей и выполните обновление. Предупредите людей заранее: принудительное завершение сеанса обрывает несохранённую работу.

Фоновое обновление

В актуальных версиях платформы 8.3 есть фоновое обновление: тяжёлая подготовка реструктуризации идёт, пока пользователи работают, а монопольный доступ нужен только на короткий финальный этап. В пакетном режиме оно управляется параметрами /UpdateDBCfg -BackgroundStart (запуск) и -BackgroundFinish (завершение). Для баз, где реструктуризация длится часами, это сокращает простой до минут.

Расширения конфигурации

Расширения появились в 8.3.6. В них удобно держать доработки, не снимая типовую с поддержки. Подключённое расширение тоже видно только новым сеансам, так что правило «перезапустите 1С» действует и здесь.

Практика для администраторов и разработчиков

• 📝 Ведите журнал изменений: дата, кто, что поменял, каким способом применили. Особенно для динамических правок.
• 🧪 Сначала копия базы, потом рабочая. Даже если правка в одну строку.
• 🕐 Динамически обновляйте в спокойные часы, а не в разгар закрытия месяца.
• 📣 После обновления — сообщение пользователям о перезапуске.
• 🔒 На критичных базах запретите динамическое обновление в скриптах ключом -Dynamic-, чтобы случайная правка не применилась «на живую».
• 🧩 Доработки типовых держите в расширениях: обновления релизов пройдут проще.