Как отменить запрос в 1С 8

Тяжёлый запрос в 1С 8 способен «повесить» сеанс пользователя на десятки минут: форма не отвечает, отчёт не строится, а на сервере растёт нагрузка. Задача отмены запроса возникает у разработчиков при отладке в консоли запросов, у администраторов — когда регламентное задание блокирует работу базы, и у пользователей — когда отчёт запущен с ошибочными отборами.

Способ отмены зависит от того, где именно выполняется запрос: в тонком или толстом клиенте, на сервере 1С:Предприятия или уже непосредственно в СУБД (MS SQL Server, PostgreSQL). Важно понимать: платформа 1С не всегда позволяет мгновенно прервать запрос, ушедший на СУБД, — иногда требуется вмешательство на уровне самой базы данных.

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

Как понять, где «застрял» запрос

Прежде чем отменять, определите, на каком уровне выполняется запрос. От этого зависит и инструмент остановки, и риски. Признаки легко различить по поведению системы.

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

Отмена запроса в клиентском приложении

В толстом клиенте и в конфигураторе (при отладке) долго выполняющийся код прерывается комбинацией Ctrl+Break. Платформа остановит выполнение в ближайшей точке, где управление возвращается встроенному языку. В режиме отладки можно также использовать команду «Остановить» в меню «Отладка».

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

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

Отмена запроса через консоль кластера 1С

В клиент-серверном варианте работы главный инструмент администратора — консоль кластера серверов 1С:Предприятия. Через неё можно найти проблемный сеанс и принудительно его завершить, что приведёт к отмене и запроса, выполняемого в его контексте.

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

Для фоновых заданий удобнее ветка «Соединения» или тот же список сеансов с фильтром по типу «Фоновое задание». Завершение такого сеанса останавливает регламентную операцию без перезапуска всего сервера.

1. 1
   Откройте консоль кластера и выберите нужный сервер 1С
2. 2
   Перейдите в раздел «Сеансы» и найдите сеанс с аномально долгим вызовом СУБД
3. 3
   Убедитесь, что это именно проблемный сеанс (пользователь, приложение, время)
4. 4
   Выделите сеанс и выполните команду «Удалить»
5. 5
   Проверьте в СУБД, что связанный процесс завершился и блокировки сняты

Завершение запроса на уровне СУБД

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

В MS SQL Server откройте Activity Monitor (Монитор активности) в SQL Server Management Studio или выполните запрос к системным представлениям sys.dm_exec_requests и sys.dm_exec_sessions, чтобы найти проблемный процесс по длительности и тексту запроса. Затем завершите его командой KILL <session_id>. Процесс отката транзакции может занять время — это нормально.

В PostgreSQL найдите зависший запрос через представление pg_stat_activity (поля state, query_start, query) и отмените его функцией pg_cancel_backend(pid) — мягкая отмена запроса, или pg_terminate_backend(pid) — принудительный разрыв соединения, если отмена не помогла.

-- PostgreSQL: отмена зависшего запроса по PID
SELECT pg_cancel_backend(12345);
-- если не помогло — принудительный разрыв
SELECT pg_terminate_backend(12345);

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

Как ограничить выполнение запросов в коде 1С

Лучшая «отмена» — та, которую не пришлось делать вручную. Во встроенном языке 1С прямого метода «отменить запрос» у объекта Запрос нет, но есть приёмы, которые предотвращают зависания.

Используйте предварительную проверку объёма данных: перед основным запросом выполните лёгкий запрос с ВЫБРАТЬ ПЕРВЫЕ 1 или подсчётом по ключевому отбору. Если выборка потенциально огромна — запросите подтверждение у пользователя или уточните отборы.

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

// Проверка объёма перед тяжёлым запросом
ЗапросПроверка = Новый Запрос(
"ВЫБРАТЬ ПЕРВЫЕ 1 Т.Ссылка ИЗ Документ.Реализация КАК Т
|ГДЕ Т.Дата МЕЖДУ &Начало И &Конец");
Если ЗапросПроверка.Выполнить().Пустой() Тогда
    Возврат; // нечего обрабатывать — тяжёлый запрос не запускаем
КонецЕсли;

Типичные ошибки и профилактика зависших запросов

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

Для профилактики настройте в СУБД ограничения на длительность запросов, где это возможно (например, statement_timeout в PostgreSQL), регулярно обновляйте статистику и следите за планами выполнения тяжёлых запросов. В 1С используйте технологический журнал с фильтром по событию DBMSSQL/DBPOSTGRS и длительности — это позволяет находить проблемные запросы до того, как пользователи начнут жаловаться.

Как проверить, что запрос действительно отменён

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

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

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