Запись заблокирована в 1С: как снять блокировку и найти её причину

Бухгалтер пытается перепровести документ , а программа отвечает: Запись не может быть изменена, так как она уже изменяется или удаляется. Запись заблокирована — объект в этот момент держит другой сеанс. Чтобы снять блокировку в 1С, нужно найти, кто и что заблокировал, и либо дождаться освобождения, либо завершить зависший сеанс. Список открытых сеансов смотрят через главное меню → Все функции → Стандартные → Активные пользователи.

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

Что блокирует запись: три разных механизма

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

• 🔒 Объектная (пессимистичная) блокировка. Срабатывает, когда пользователь открыл документ или элемент справочника на редактирование. Пока форма открыта, объект держится, и второй пользователь получает Объект заблокирован или Данные не могут быть изменены, так как они используются другим пользователем.
• 🔁 Транзакционная блокировка. Возникает в момент записи и проведения. Платформа на доли секунды закрывает нужные таблицы, чтобы итоги и остатки сошлись. При высокой нагрузке появляется Конфликт блокировок при выполнении транзакции.
• 🏢 Блокировка всей информационной базы. Это не про одну запись, а про всю базу: монопольный режим для обновления или административная блокировка начала сеансов. Её ставят специально, а не она «возникает».

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

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

Частые причины, почему запись «висит»

• ⏳ Коллега открыл документ и ушёл на обед, оставив форму открытой.
• 💻 Сеанс завис: компьютер ушёл в спящий режим или оборвалась связь с сервером, а на стороне кластера сеанс числится живым.
• 📊 Длинный отчёт или обработка держат таблицы дольше таймаута.
• 🔧 Администратор включил блокировку начала сеансов перед обновлением и забыл снять.

Как найти активный сеанс и его владельца

Первый шаг всегда один — посмотреть, кто сейчас в базе.

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

В консоли администрирования сервера. Если база клиент-серверная, разверните в оснастке дерево Кластер → ваш кластер → Информационные базы → нужная база → Сеансы. Здесь видно больше: захваченные соединения, активность СУБД, объём занятой памяти по каждому сеансу.

Через журнал регистрации. Чтобы понять, какой именно объект блокируется, откройте журнал регистрации (Все функции → Стандартные → Журнал регистрации) и отфильтруйте события по пользователю и времени. Так находят документ, на котором всё встало.

Для командной строки есть утилита rac. Безопасные команды для диагностики:

rac cluster list
rac session list --cluster=<идентификатор кластера>

Первая покажет идентификатор кластера, вторая — список сеансов с их UUID. Если не уверены в параметрах — посмотрите подсказку командой rac help, выдумывать ключи не нужно.

Снятие объектной блокировки штатными средствами

Самый частый случай — именно объектная блокировка, и снимается она без администратора.

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

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

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

Принудительное завершение зависшего сеанса администратором

Если сеанс завис и владелец не может его закрыть, завершает его администратор.

Клиент-серверная база. В консоли администрирования: Кластер → Информационные базы → база → Сеансы, щёлкните правой кнопкой по нужному сеансу → Удалить. Соединение разорвётся, блокировка освободится.

Через утилиту rac то же самое делается так:

rac session list --cluster=<id кластера>
rac session terminate --cluster=<id кластера> --session=<UUID сеанса>

UUID берётся из вывода rac session list. Завершайте точечно нужный сеанс, а не все подряд.

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

Монопольный режим для обновления и обслуживания

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

Порядок действий:

1. Предупредите пользователей и назначьте окно — например, обеденный перерыв или вечер.
2. В клиент-серверной базе откройте свойства информационной базы в консоли кластера и включите Блокировка начала сеансов включена. Задайте Код разрешения — произвольную строку-пароль.
3. Этот код позволит вам войти, пока остальные уже не могут: админ запускает 1С с параметром /UC<код> в строке запуска (например, /UCadmin).
4. Дождитесь, пока текущие сеансы завершатся сами, либо завершите их принудительно (см. выше).
5. Выполните обновление или обслуживание.
6. Обязательно снимите блокировку начала сеансов после окончания работ — иначе пользователи утром не войдут в базу.

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

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

Конфликт блокировок при проведении: настройка и профилактика

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

Режим управления блокировкой данных. В Конфигураторе откройте свойства корня конфигурации и проверьте параметр Режим управления блокировкой данных. Управляемый режим накладывает блокировки точнее и даёт меньше конфликтов, чем автоматический. Современные типовые конфигурации работают в управляемом режиме; у сильно доработанных старых баз иногда остаётся автоматический — это и есть источник частых конфликтов.

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

Что снижает число конфликтов на практике:

• 🕐 Переносите тяжёлые обмены и регламентные задания на ночь или обеденное окно.
• 📝 Не оставляйте документы открытыми на редактирование надолго — закрывайте форму сразу после ввода.
• 📦 Проводите большие пачки документов группами, а не всю номенклатуру разом в пиковые часы.
• 🧹 Регулярно делайте Тестирование и исправление и реиндексацию — распухшая база дольше держит таблицы.
• ⚙️ Проверьте доработки: длинные транзакции в самописном коде часто и держат блокировки дольше нужного.

Отдельно стоит взаимоблокировка (deadlock) — когда два сеанса ждут друг друга по кругу. Платформа сама обрывает одну из транзакций с ошибкой. Если такое повторяется, разбираться нужно в порядке обращения к данным в конкретной обработке — это задача для специалиста по платформе.

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

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

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