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

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

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

Что значит «объект заблокирован» в 1С

Под блокировкой в 1С понимают несколько разных состояний. Первая группа — транзакционные блокировки: пока один сеанс изменяет объект внутри транзакции, другой сеанс не может его записать или заблокировать. В файловом режиме такие блокировки обрабатывает сама платформа, в клиент-серверном — MS SQL Server, PostgreSQL или Oracle.

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

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

Проверка блокировки из кода: Попытка / Исключение

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

Типовой фрагмент кода выглядит так:

ОбъектДанных = СсылкаНаДокумент.ПолучитьОбъект();
Попытка
ОбъектДанных.Заблокировать();
Исключение
Сообщить("Объект заблокирован другим сеансом: "
+ ОписаниеОшибки());
Возврат;
КонецПопытки;

Метод Заблокировать() устанавливает объектную блокировку до конца транзакции или до вызова Разблокировать(). Если другой сеанс уже заблокировал этот объект, будет вызвано исключение с текстом о конфликте блокировок. Именно этот приём используют в обменах данными и фоновых заданиях, чтобы корректно обрабатывать занятые объекты, а не падать с ошибкой.

Важное ограничение: метод Заблокировать() вызывается только у объектного типа (результат ПолучитьОбъект()), а не у ссылки. Для проверки без загрузки всего объекта в память применяют управляемую блокировку через БлокировкаДанных — она работает по ссылке и не читает данные объекта.

Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("Документ.РеализацияТоваровУслуг");
Элемент.УстановитьЗначение("Ссылка", СсылкаНаДокумент);
Попытка
    Блокировка.Заблокировать();
Исключение
    Сообщить("Объект заблокирован: " + ОписаниеОшибки());
КонецПопытки;

Как найти виновника блокировки через журнал регистрации

Когда пользователь сообщает «не могу провести документ — конфликт блокировок», первый инструмент администратора — журнал регистрации. Откройте его через «Администрирование → Обслуживание → Журнал регистрации» (в типовых конфигурациях) или через конфигуратор: «Администрирование → Журнал регистрации».

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

1. 1
   Откройте журнал регистрации в режиме предприятия или конфигуратора
2. 2
   Установите отбор по уровню «Ошибка» за нужный период
3. 3
   В отборе по данным укажите слово «блокировк»
4. 4
   Откройте найденное событие и посмотрите сеанс и пользователя
5. 5
   Найдите этот сеанс в списке активных сеансов и при необходимости завершите его

Учтите ограничение: детализация зависит от настроек регистрации событий и режима работы. В клиент-серверном варианте часть информации о взаимоблокировках фиксируется только на стороне СУБД — тогда нужны технологический журнал платформы или средства самой СУБД.

Проверка через консоль кластера и список сеансов

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

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

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

Проверка логических блокировок: дата запрета, права, RLS

Если ошибки «конфликт блокировок» нет, а объект всё равно не редактируется, причина почти всегда в логических ограничениях. Проверьте три вещи.

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

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

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

Взаимоблокировки и технологический журнал

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

Для глубокой диагностики включают технологический журнал платформы с событиями TLOCK, TDEADLOCK и TTIMEOUT. Файл настройки logcfg.xml размещается в каталоге conf сервера 1С, а собранные логи анализируют по времени и сеансам. Это инструмент администратора или программиста — настройка требует аккуратности, так как интенсивное логирование замедляет работу сервера.

Типичные ошибки при диагностике и работе с блокировками

Самая частая ошибка разработчика — попытка «проверить» блокировку чтением объекта. Чтение по ссылке не устанавливает и не проверяет блокировку: объект может быть заблокирован другим сеансом, а ПолучитьОбъект() отработает без ошибки. Конфликт обнаружится только при записи или при вызове Заблокировать().

Вторая ошибка — ставить управляемую блокировку вне транзакции. Управляемые блокировки имеют смысл только внутри явной транзакции (НачатьТранзакцию / ЗафиксироватьТранзакцию), иначе они снимаются немедленно и не защищают данные.

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

FAQ