Объект заблокирован в 1С: как узнать, кем, и что делать

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

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

Что означает сообщение о блокировке объекта

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

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

Отдельный случай — сообщение «Объект заблокирован» при попытке открыть форму в конфигурациях с механизмом блокировки объектов для редактирования (например, в типовых решениях на БСП). Там блокировка ставится явно при открытии формы и снимается при её закрытии, а в тексте ошибки обычно сразу указан пользователь, который редактирует объект.

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

Самый простой путь — внимательно прочитать текст ошибки. В конфигурациях на Библиотеке стандартных подсистем сообщение обычно содержит имя пользователя и компьютер: «Не удалось заблокировать объект... Он редактируется пользователем Иванов И.И. (компьютер WS-045)». Если такая информация есть — дальше достаточно связаться с коллегой и попросить закрыть форму.

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

Когда в сообщении пользователя нет (типично для конфликтов транзакций), источники информации такие:

• консоль кластера серверов 1С — раздел «Сеансы» и «Блокировки»;
• журнал регистрации — события с ошибками блокировок и действия пользователей по объекту;
• технологический журнал — события TLOCK, TDEADLOCK для глубокой диагностики;
• типовая обработка «Активные пользователи» (Администрирование → Обслуживание) — список сеансов с возможностью завершения.

1. 1
   Прочитайте текст ошибки: часто там уже указан пользователь и компьютер
2. 2
   Откройте список активных сеансов (консоль кластера или «Активные пользователи»)
3. 3
   Найдите сеанс пользователя и проверьте, жив ли он: время последнего вызова, открытые объекты
4. 4
   Попросите пользователя закрыть форму объекта или завершите зависший сеанс
5. 5
   Повторите операцию и убедитесь, что объект записывается без ошибок

Диагностика в клиент-серверной базе

В клиент-серверном варианте основной инструмент — консоль кластера серверов 1С. Откройте ветку нужной базы, раздел «Сеансы», и отсортируйте по времени последнего вызова: зависший сеанс обычно долго не проявляет активности, но числится спящим. В разделе «Блокировки» видно, какие объекты СУБД удерживаются каждым соединением.

Полезно сопоставить сеанс 1С с процессом на SQL-сервере. В Microsoft SQL Server активные блокировки видны через Activity Monitor или запрос к sys.dm_tran_locks и sys.dm_exec_sessions — по ним видно, какой процесс держит ресурс и кого он блокирует. В PostgreSQL аналогичную картину даёт представление pg_locks в связке с pg_stat_activity.

SELECT * FROM pg_locks l JOIN pg_stat_activity a ON l.pid = a.pid WHERE NOT l.granted;

Если конфликты повторяются систематически, включите сбор технологического журнала с событиями TLOCK и TDEADLOCK. Лог покажет, какие запросы конфликтуют, какие таблицы участвуют и какой запрос был выбран жертвой взаимоблокировки — это уже повод анализировать код или настройки конфигурации, а не только «гасить» сеансы.

Диагностика в файловой базе

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

Характерная ситуация для файловой базы: пользователь закрыл 1С аварийно (обрыв сети, перезагрузка, снятие процесса), а сеанс в списке остался. Такой «мёртвый» сеанс может удерживать блокировку и мешать другим. Решение — завершить его из списка активных пользователей или перезапустить службу/процесс, обслуживающий файловую базу, если публикация идёт через веб-сервер.

Ещё один признак проблемы — файл 1Cv8.1CL в каталоге базы при отсутствии реальных подключений. Удалять его вручную можно только когда точно никто не работает с базой, иначе есть риск повредить данные.

Типовые сценарии возникновения блокировок

Пользователь открыл объект и отошёл

Самый частый случай. Форма документа открыта в режиме редактирования, сотрудник ушёл на совещание, а коллега не может провести тот же документ или связанный заказ. Решение — попросить закрыть форму; на будущее полезно донести до пользователей правило: закончил работу — закрой объект.

Зависший сеанс

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

Фоновые и регламентные задания

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

Взаимоблокировка (deadlock)

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

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

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

Порядок безопасного снятия блокировки:

1. Идентифицируйте сеанс, удерживающий объект (пользователь, компьютер, время активности).
2. Свяжитесь с пользователем и попросите завершить работу с объектом штатно.
3. Если сеанс завис — завершите его принудительно из консоли кластера или списка активных пользователей.
4. Подождите 1–2 минуты: СУБД должна откатить незавершённую транзакцию и освободить ресурсы.
5. Повторите операцию. Если ошибка сохраняется — ищите второй сеанс или фоновое задание.

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

Профилактика: как снизить число конфликтов

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

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

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