Принудительное отключение пользователей от базы 1С

Быстрый путь зависит от того, какая у вас база. В клиент-серверной работают три инструмента: блокировка новых сеансов в типовой конфигурации (Администрирование → Обслуживание), раздел «Сеансы» в консоли администрирования серверов и команда rac session terminate из командной строки. В файловой базе отдельного сервера нет — там выгнать человека «кнопкой» нельзя, остаётся блокировка средствами конфигурации.

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

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

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

Блокировка работы пользователей в режиме Предприятия

Это штатный и самый безопасный способ в типовых конфигурациях на библиотеке стандартных подсистем (БП 3.0, ЗУП 3.1, УТ 11, ERP, УНФ). Он не рвёт сеансы мгновенно, а закрывает вход и мягко выпроваживает людей.

Откройте раздел Администрирование → Обслуживание → Блокировка работы пользователей. В форме задаются:

• 🕒 дата и время, с которых вход блокируется;
• ✉️ текст сообщения, которое увидят пользователи («Идёт обновление, завершите работу до 18:00»);
• 🔑 код разрешения — пароль, с которым администратор сможет войти в заблокированную базу.

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

В клиент-серверном режиме у администратора в типовой конфигурации есть и форма «Активные пользователи» (в том же разделе «Обслуживание»): она показывает список подключений и позволяет завершить выбранный сеанс кнопкой в командной панели списка. В файловой базе эта кнопка неактивна — завершать там нечего, сервера нет.

Завершение сеанса через консоль администрирования серверов

Для клиент-серверной базы самый наглядный инструмент — консоль администрирования серверов 1С:Предприятия. Это оснастка MMC, которая ставится вместе с платформой (компонент «Администрирование сервера 1С»).

Если в меню «Пуск» оснастки нет или она не открывается, зарегистрируйте её библиотеку из каталога bin установленной платформы:

regsvr32 "C:\Program Files\1cv8\8.3.24.1234\bin\radmin.dll"

Номер версии подставьте свой — тот, что реально установлен. Это частая причина, по которой консоль «пропадает» после обновления платформы: radmin.dll новой версии не перерегистрировали.

Дальше порядок такой:

1. Откройте консоль, разверните узел Central 1C:Enterprise 8.3 servers.
2. Перейдите в <ваш сервер> → Кластеры → <кластер> → Сеансы.
3. В списке найдите нужного пользователя (колонки «Пользователь», «Приложение», «Активность»).
4. Щёлкните сеанс правой кнопкой и выберите удаление сеанса.

Рядом есть ветка «Соединения» — иногда соединение остаётся, даже когда сеанс уже снят; его закрывают тем же способом. Если вход в кластер защищён паролем администратора кластера, консоль спросит логин и пароль — это не пароль пользователя базы.

Утилита rac: отключение сеансов из командной строки

Когда действий много или их надо автоматизировать (скрипт перед ночным обновлением), удобнее утилита администрирования rac. Она лежит в том же каталоге bin и работает через агент сервера (по умолчанию порт 1540).

Сначала узнайте идентификатор кластера:

rac cluster list

В выводе будет строка cluster : <uuid>. С этим идентификатором смотрите список сеансов:

rac session list --cluster=<cluster-uuid>

Каждый сеанс печатается со своим session : <uuid>, именем пользователя и приложением. Нужный сеанс завершают по его идентификатору:

rac session terminate --cluster=<cluster-uuid> --session=<session-uuid>

Если кластер или база защищены, добавьте учётные данные: --cluster-user и --cluster-pwd для кластера, --infobase-user и --infobase-pwd для базы. Полный перечень ключей всегда можно посмотреть в справке — rac help и rac session help; не придумывайте параметры наугад.

Идентификатор сеанса (session : <uuid>) у каждого подключения свой и меняется при переподключении, поэтому в скрипте список сеансов получают заново перед каждым завершением, а не сохраняют «на завтра». Отфильтровать по конкретному человеку удобно по колонке с именем пользователя в выводе rac session list.

Как закрыть доступ к файловой базе

С файловой базой принципиально иначе. Нет ни кластера, ни агента сервера — значит, нет и центральной точки, которая могла бы «выкинуть» чужой сеанс. Команды rac и консоль администрирования к файловой базе неприменимы.

Что реально работает:

• 🔒 Блокировка средствами конфигурации. Форма «Блокировка работы пользователей» (см. первый раздел) пишет признак блокировки в саму базу, поэтому действует и в файловом варианте. Остальные выйдут при следующем действии — это главный цивилизованный способ.
• 🗣️ Договориться и дождаться. Для обновления или загрузки .dt всё равно нужен монопольный доступ: достаточно, чтобы все закрыли программу. Форма «Активные пользователи» покажет, кто ещё в базе.
• 💻 Физически на рабочем месте. Если конкретный компьютер завис и недоступен по сети, сеанс закрывается только там — закрытием окна 1С или перезагрузкой машины.

Не удаляйте служебные файлы блокировки (например, из каталога базы) при подключённых пользователях — так можно повредить базу. Файловая СУБД сама снимет блокировки, когда последний клиент корректно выйдет.

Если база файловая, но лежит на сервере и к ней подключаются по сети, перевод её в клиент-серверный режим (публикация на сервере 1С) как раз и решает проблему управляемости: появляются и консоль, и rac. Для небольших баз на три-пять рабочих мест переходить на сервер ради одного только управления сеансами обычно не стоит — хватает плановой блокировки с заранее объявленным временем.

Завершение сеансов обработкой на встроенном языке

Иногда отключение встраивают в собственный регламент — например, обработка перед обновлением сама закрывает вход и снимает оставшиеся сеансы. В клиент-серверном режиме платформа даёт для этого серверные методы.

Получить список текущих сеансов можно методом ПолучитьСеансыИнформационнойБазы() — он возвращает массив объектов с данными о пользователе, приложении и времени последней активности. Завершить выбранные сеансы позволяет метод УдалитьСеансыИнформационнойБазы(), которому передают массив сеансов.

Общая логика такой обработки:

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

Для автоматизации без изменения конфигурации чаще берут не встроенный язык, а связку rac + bat-файл по расписанию: список сеансов → завершение → установка запрета входа. Так регламент не зависит от обновлений типовой.

Остановка регламентных и фоновых заданий

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

Запретить их запуск можно двумя путями:

• В консоли администрирования: откройте свойства информационной базы (ветка Информационные базы → <база> → свойства) и включите флаг блокировки регламентных заданий. Новые задания стартовать не будут.
• Через rac: при обновлении параметров базы задают запрет регламентных заданий одновременно с запретом сеансов (rac infobase update с соответствующими ключами). Точные имена ключей смотрите в rac infobase help.

Уже запущенное фоновое задание флаг не прерывает — оно доработает до конца. Дайте ему завершиться либо (в крайнем случае) снимите его соединение в разделе «Соединения» консоли.

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

Как спланировать работы и никого не выгонять вручную

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

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

Код разрешения из блокировки передаётся платформе параметром /UC. Запуск выглядит так:

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" ENTERPRISE /S"server\base" /UCobnovlenie

Для файловой базы вместо /S указывают путь /F"D:\Bases\Buh". Параметр /UC без пробела соединяется с кодом разрешения.

Если работы вышли за окно и кто-то успел снова зайти — не ругайтесь на людей, а продлите блокировку: обновите время и сообщение, и новые входы снова закроются.

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

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