Начало сеанса с информационной базой запрещено в 1С: причины и решение

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

Способ снятия блокировки зависит от режима работы базы: файлового или клиент-серверного. В файловом варианте достаточно удалить или отредактировать служебный файл 1Cv8.cdn в каталоге базы. В клиент-серверном варианте блокировка хранится в свойствах информационной базы в консоли кластера серверов 1С. Ниже разобраны оба сценария с пошаговыми действиями и проверкой результата.

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

Почему возникает блокировка сеансов

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

Основные причины появления сообщения:

• Ручная установка администратором — перед обновлением конфигурации, загрузкой данных или регламентными работами администратор включает блокировку через консоль кластера или обработку «Блокировка работы пользователей».
• Автоматическая блокировка при обновлении — типовые конфигурации при динамическом обновлении или обновлении через поддержку сами устанавливают блокировку и должны снять её по завершении. Если процесс прервался (отключение электричества, перезагрузка сервера, ошибка обновления), блокировка остаётся.
• Установленное время начала блокировки — блокировка может быть запланирована на будущее и включиться по расписанию, например ночью перед плановым обновлением.
• Скрипты обслуживания — пакетные задания резервного копирования или обслуживания могут включать блокировку через параметры командной строки конфигуратора.

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

Как снять блокировку в клиент-серверном варианте

В клиент-серверной архитектуре блокировка хранится в свойствах информационной базы в кластере серверов 1С. Для её снятия нужны административные права на кластер.

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

Если консоль кластера недоступна (например, вы работаете удалённо и есть только доступ к серверу СУБД), блокировку можно снять через параметры запуска конфигуратора: запустите конфигуратор и через меню «Администрирование — Параметры информационной базы» проверьте состояние блокировки. В ряде случаев удобнее воспользоваться пакетным режимом с параметром отключения блокировки.

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

Как снять блокировку в файловой базе

В файловом варианте блокировка реализуется через служебный файл 1Cv8.cdn (файл блокировки соединений), который создаётся в каталоге информационной базы рядом с файлом 1Cv8.1CD. Пока этот файл существует и содержит актуальные параметры блокировки, платформа отклоняет начало сеансов.

Порядок действий прост: закройте все активные сеансы работы с базой, откройте каталог базы и удалите файл 1Cv8.cdn. После этого пользователи смогут войти. Если файл нужно сохранить «на всякий случай», его можно не удалять, а переименовать — платформа перестанет его учитывать.

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

Снятие блокировки изнутри базы и через код разрешения

Если при установке блокировки был задан код разрешения, администратор может войти в базу, указав этот код в параметре запуска /UC<код> или в специальной строке при старте тонкого клиента через параметр UC. Войдя с административными правами, можно снять блокировку штатными средствами конфигурации.

В типовых конфигурациях (Бухгалтерия предприятия, Управление торговлей, Зарплата и управление персоналом и других на БСП) используется обработка «Блокировка работы пользователей»: раздел «Администрирование — Обслуживание — Блокировка работы пользователей». В ней нажмите «Снять блокировку» — конфигурация обновит параметры блокировки соединений на уровне платформы.

Также в типовых решениях есть сервисная команда: запуск в режиме предприятия с параметром /CРазрешитьРаботуПользователям снимает блокировку при старте сеанса, если у пользователя достаточно прав. Это удобно для скриптов обслуживания.

1cv8.exe ENTERPRISE /F"C:\Bases\Trade" /N"Администратор" /P"пароль" /UCКодРазрешения /CРазрешитьРаботуПользователям

Блокировка после обновления конфигурации: особый случай

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

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

Если обновление завершилось с ошибкой и откат невозможен, безопасный путь — восстановить базу из резервной копии, сделанной до обновления, и повторить процедуру. Работа пользователей в частично обновлённой базе создаёт риск порчи данных, который проявится значительно позже.

Как проверить, что проблема решена

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

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

Профилактика: как не допустить повторения

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

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

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