Как прервать выполнение обработки в 1С 8

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

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

Ниже разобраны все практические варианты: от штатного прерывания по Ctrl+Break до принудительного завершения сеанса и отмены запроса на уровне СУБД, а также приёмы, которые позволяют проектировать обработки так, чтобы их можно было остановить штатно.

Как прервать обработку сочетанием Ctrl+Break

Классический способ остановить выполняющийся код — нажать Ctrl+Break в клиентском приложении. Однако работает он не всегда. Во-первых, прерывание доступно только в толстом клиенте: в тонком клиенте и веб-клиенте сочетание Ctrl+Break не останавливает серверный код, так как исполнение происходит на сервере, а не на машине пользователя.

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

В-третьих, даже при разрешённом прерывании остановка произойдёт не мгновенно, а в ближайшей контрольной точке исполнения — между операторами встроенного языка. Если в данный момент выполняется длинный запрос к СУБД или платформенная операция (например, запись большого набора данных), Ctrl+Break сработает только после её завершения.

Завершение сеанса через консоль кластера

Если клиентское приложение зависло и не отвечает, сеанс пользователя можно завершить принудительно со стороны сервера. Для клиент-серверного варианта работы откройте консоль кластера серверов 1С, найдите нужный сеанс в списке и выполните команду удаления сеанса. Рабочий процесс прервёт выполнение кода этого сеанса, открытые транзакции будут откачены СУБД.

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

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

Остановка фоновых заданий

Многие длительные обработки в современных конфигурациях запускаются как фоновые задания — например, через механизм «Длительные операции» БСП. Пользователь видит индикатор прогресса и кнопку «Отмена», но штатная отмена работает, только если код обработки проверяет признак отмены.

Программно фоновое задание отменяется методом Отменить() объекта ФоновоеЗадание: найдите задание по уникальному идентификатору или отбором по имени метода через ФоновыеЗадания.ПолучитьФоновыеЗадания() и вызовите отмену. Учтите: метод сигнализирует о необходимости остановки, но фактическое прерывание происходит на стороне сервера не мгновенно.

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

Отбор = Новый Структура("ИмяМетода", "МоиОбработки.ДлительнаяОбработка");
Задания = ФоновыеЗадания.ПолучитьФоновыеЗадания(Отбор);
Для Каждого Задание Из Задания Цикл
    Если Задание.Состояние = СостояниеФоновогоЗадания.Активно Тогда
        Задание.Отменить();
    КонецЕсли;
КонецЦикла;

Прерывание запроса на уровне СУБД

Если обработка зависла внутри тяжёлого запроса, самый надёжный способ остановки — отмена запроса средствами СУБД. В MS SQL Server это делается командой KILL по идентификатору процесса (SPID), который виден в Activity Monitor или через sys.dm_exec_requests. В PostgreSQL используются функции pg_cancel_backend (мягкая отмена запроса) и pg_terminate_backend (разрыв соединения).

Идентификатор процесса СУБД удобно сопоставить с сеансом 1С через консоль кластера — там отображается номер соединения с базой данных. Это исключает риск «убить» чужой запрос.

Отмена запроса на стороне СУБД приводит к ошибке в сеансе 1С: пользователь увидит сообщение об ошибке СУБД, транзакция будет откачена. Это нормальное и безопасное поведение, но применять способ следует осознанно и только при наличии прав администратора СУБД.

Как сделать обработку прерываемой при разработке

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

Второй приём — порционная обработка с транзакциями. Вместо одной гигантской транзакции на всю обработку фиксируйте изменения пакетами (например, по 100–500 объектов) и сохраняйте прогресс. Тогда прерывание в любой точке оставит базу в консистентном состоянии, а повторный запуск продолжит с места остановки.

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

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

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

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

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