Почему возникает ошибка «Автоматический режим блокировки недопустим в этой транзакции» при удалении документа?

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

Понимание природы ошибки

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

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

Метод 1: Поиск и перевод связанных объектов в управляемый режим

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

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

Для исправления проблемы последовательно переведите все вышеуказанные объекты в состояние «Управляемый» в свойствах конфигуратора.

Метод 2: Программная обработка удаления в транзакции

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

НачатьТранзакцию();
Попытка
    ОбъектУдаления = СсылкаНаОбъект.ПолучитьОбъект();
    Если ОбъектУдаления <> Неопределено Тогда
        ОбъектУдаления.Удалить();
    КонецЕсли;
    ЗафиксироватьТранзакцию();
Исключение
    ОтменитьТранзакцию();
    Сообщить(ОписаниеОшибки());
КонецПопытки;

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

Метод 3: Временная смена режима для объекта (временное решение)

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

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

Этот метод следует использовать с осторожностью, так как он является «костылем» и не устраняет саму причину архитектурного конфликта.

Рекомендации по диагностике

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

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