Работа с базой 1С в одиночку: когда платформе нужен монопольный доступ

Монопольный режим в 1С — это состояние, когда с информационной базой работает ровно один сеанс, а все остальные подключения запрещены. Включить его «галочкой» нельзя: платформа сама пытается захватить базу монопольно перед операцией, которой это нужно, и отказывает, если в базе есть хоть один чужой сеанс — пользователь, фоновое задание или зависший процесс.

Частое заблуждение — что любой вход в Конфигуратор блокирует базу для всех. Это не так. Пользователи спокойно работают, пока вы правите конфигурацию. Монопольный доступ понадобится в момент, когда изменения надо применить к структуре базы, загрузить файл .dt или запустить тестирование и исправление. Всё ниже относится к платформе 1С:Предприятие 8.3 и не зависит от конфигурации: в БП 3.0, ЗУП 3.1 и УТ 11 механизм одинаковый.

Что блокирует монопольный режим и для каких операций он нужен

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

Операции, для которых монопольный доступ обязателен:

• 🔧 Обновление конфигурации базы данных с реструктуризацией — когда меняются реквизиты, табличные части, состав объектов. Это происходит и при установке обновления типовой конфигурации.
• 📥 Загрузка информационной базы из файла .dt (Администрирование → Загрузить информационную базу в Конфигураторе). Загрузка полностью заменяет данные, поэтому работать в это время никому нельзя.
• 🩺 Тестирование и исправление (Администрирование → Тестирование и исправление): проверка логической и ссылочной целостности, пересчёт итогов, реиндексация, сжатие таблиц.
• ⚙️ Код, который сам запросил монопольный режим. Некоторые обработки и обработчики обновления вызывают УстановитьМонопольныйРежим(Истина) и работают только в одиночку.

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

Монопольный, «эксклюзивный» и обычный многопользовательский режим

Путаница в терминах сбивает с толку при поиске решений. Разложим по полочкам.

«Эксклюзивный» режим — это тот же монопольный. В англоязычной версии платформы метод называется SetExclusiveMode(), отсюда и калька. Отдельного режима с таким названием в 1С нет.

Зато есть механизмы, которые похожи по результату, но работают иначе:

Блокировка начала сеансов — главный помощник монопольного режима. Она не даёт пользователям зайти обратно, пока вы готовитесь, а сам монопольный режим устанавливает уже операция обновления или загрузки.

Как перейти в монопольный режим: пошагово для файловой и серверной базы

Схема одна: предупредить людей, запретить новые входы, завершить оставшиеся сеансы, выполнить операцию, снять запрет. Различается только инструмент.

Файловая база

1. Откройте базу в режиме 1С:Предприятие под администратором.
2. Перейдите в Администрирование → Обслуживание и найдите команду блокировки работы пользователей. В некоторых релизах БП раздел называется «Поддержка и обслуживание».
3. Включите блокировку, задайте сообщение («Обновление базы до 14:30») и код разрешения, например upd2026.
4. Платформа в течение нескольких минут попросит пользователей сохраниться и завершит их сеансы.
5. Откройте Конфигуратор с ключом кода разрешения, иначе он сам не войдёт в заблокированную базу. Ключ /UC указывается в дополнительных параметрах запуска базы в списке или в командной строке.
6. Проверьте Администрирование → Активные пользователи в Конфигураторе: в списке должны остаться только вы.
7. После операции снимите блокировку в той же форме.

Клиент-серверная база

Здесь блокировку ставят на уровне кластера, а не в самой конфигурации.

1. Откройте консоль администрирования серверов 1С и найдите нужную информационную базу.
2. В свойствах базы включите «Блокировка начала сеансов включена», заполните сообщение, код разрешения и при необходимости время начала и окончания.
3. Там же включите «Блокировка регламентных заданий включена». Иначе фоновые задания обмена или загрузки курсов создадут новые сеансы и сорвут установку монопольного режима.
4. В разделе «Сеансы» базы посмотрите, кто остался, и удалите лишние сеансы.
5. Выполните операцию в Конфигураторе, запущенном с кодом разрешения.
6. Снимите обе блокировки.

Если удобнее командная строка, то же самое делает утилита rac через свойства базы (rac infobase update с параметрами запрета сеансов и регламентных заданий). Набор параметров зависит от версии платформы — сверьтесь с rac help infobase на своём сервере. Посмотреть живые сеансы можно командой rac session list.

Пакетный запуск для ночного обновления

Если обновление идёт по расписанию, всё собирают в один командный файл:

rem 1. Запретить вход и выгнать пользователей (механизм БСП)
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" ENTERPRISE /F"D:\Bases\Buh" /N"Админ" /P"пароль" /C"ЗавершитьРаботуПользователей" /UC"upd2026"

rem 2. Обновить конфигурацию базы данных
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Админ" /P"пароль" /UC"upd2026" /UpdateDBCfg /Out"D:\Logs\upd.log"

rem 3. Разрешить вход
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" ENTERPRISE /F"D:\Bases\Buh" /N"Админ" /P"пароль" /C"РазрешитьРаботуПользователей" /UC"upd2026"

Номер платформы в пути подставьте свой. Для серверной базы вместо /F"путь" указывают /S"сервер\имя_базы". Пароль в открытом виде в bat-файле — риск: держите файл в папке, доступной только администратору.

Из встроенного языка

Разработчик может запросить монопольный режим прямо в коде:

Попытка
    УстановитьМонопольныйРежим(Истина);
Исключение
    Сообщить("В базе есть другие сеансы. Завершите их и повторите.");
    Возврат;
КонецПопытки;

Попытка
    // операция, которой нужен единоличный доступ
    ВыполнитьПерерасчет();
Исключение
    УстановитьМонопольныйРежим(Ложь);
    ВызватьИсключение;
КонецПопытки;

УстановитьМонопольныйРежим(Ложь);

Проверить текущее состояние можно функцией МонопольныйРежим() — она возвращает Истина или Ложь. Главное правило: всегда снимайте режим и в ветке ошибки, иначе база останется закрытой до конца сеанса.

Почему не удаётся установить монопольный режим

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

Отдельный случай — ошибка блокировки базы для конфигурирования. Это не монопольный режим: так платформа сообщает, что Конфигуратор этой базы уже открыт кем-то другим. Найдите второй сеанс Конфигуратора в списке активных пользователей.

Чем монопольный режим опасен для работы базы

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

• ⏳ Простой. Реструктуризация крупной базы идёт от минут до нескольких часов. Всё это время никто не проводит документы и не печатает счета.
• 💾 Потеря несохранённого. Принудительное завершение сеанса стирает то, что пользователь не записал.
• 🔁 Сорванные обмены. Если в момент блокировки шёл обмен с другой базой или ЭДО, пакет может прийти повторно или не уйти. После снятия блокировки проверьте последние обмены.
• 🔒 Забытая блокировка. Администратор снял монопольный режим, но не снял блокировку начала сеансов. Утром офис не может войти, а сообщение висит со вчерашним текстом.
• 💥 Сбой посреди реструктуризации. Отключение питания или обрыв связи с СУБД в этот момент может оставить базу в неконсистентном состоянии.

Перед обновлением структуры и загрузкой .dt сделайте резервную копию: выгрузку .dt или бэкап средствами СУБД. Загрузка .dt молча затирает текущие данные — копия единственный путь назад.

Когда можно обойтись без монопольного режима

Выгонять всех ради каждой мелочи не нужно. Платформа 8.3 даёт несколько обходных путей.

• Динамическое обновление. Если изменения не затрагивают структуру хранения — например, правка модуля или формы, — Конфигуратор может применить их без монопольного доступа. Пользователи получат новую версию после перезапуска сеанса. Для типовых обновлений с изменением реквизитов этот путь не подходит.
• Фоновое обновление в клиент-серверной базе. Платформа готовит новую структуру в фоне, пока люди работают. Монопольный доступ нужен только на финальном этапе применения, и он занимает заметно меньше времени, чем полная реструктуризация.
• Расширения конфигурации . Доработку можно вынести в расширение. Его подключение тоже меняет структуру, если в нём есть новые данные, но правка кода в расширении обычно применяется без выгона всех.
• Выгрузка базы в .dt. Выгрузка для архива монопольного доступа не требует, хотя для согласованной копии лучше делать её, когда документы никто не проводит.
• Копия базы для экспериментов. Тестировать обработку, которой нужен монопольный режим, удобнее на копии, развёрнутой из свежего .dt. Рабочая база в это время не простаивает.

Как администратору организовать работу с монопольным режимом

Монопольный доступ проходит без нервов, когда для него есть порядок. Чек-лист на одно окно обслуживания:

Несколько приёмов из практики:

1. Код разрешения — уникальный на каждое окно. Не используйте постоянный код, который знают все программисты: кто-нибудь зайдёт в разгар обновления.
2. Время в блокировке — с запасом. Если в консоли задано время окончания, блокировка снимется сама. Ставьте его с запасом в час, а снимайте вручную, когда проверите базу.
3. Пишите журнал. Параметр /Out в пакетном запуске сохраняет ход операции в файл. Утром видно, на каком шаге всё остановилось.
4. Знайте, кто запускает фоновые задания. В базах с обменами, ЭДО и интеграцией с сайтом сеансы порождаются каждую минуту. Без блокировки регламентных заданий монопольный режим там не установится.
5. Проверяйте терминальный сервер . На нём у пользователей часто остаются отключённые, но не завершённые сессии Windows с открытой 1С. Их видно в диспетчере задач сервера на вкладке пользователей.

Частые вопросы