Как проверить запрос 1С: пошаговое руководство

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

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

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

Какие инструменты нужны для проверки запроса

Основной инструмент — конфигуратор 1С с отладчиком. Он позволяет остановиться в точке останова до выполнения запроса, посмотреть значения параметров и выполнить запрос пошагово. Отладчик запускается через меню «Отладка» → «Начать отладку» или клавишей F5, при этом база должна быть запущена в отладочном режиме.

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

Третий уровень — анализ производительности. Для файловых баз достаточно замера времени выполнения. Для клиент-серверных баз на MS SQL Server или PostgreSQL полезен план запроса на стороне СУБД, который показывает, используются ли индексы и где происходит полное сканирование таблиц.

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

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

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

Проверка динамически формируемых запросов

Если текст запроса собирается конкатенацией строк, синтаксис проверяется только в момент выполнения. В этом случае выведите итоговый текст через Сообщить() или запишите в переменную и посмотрите в отладчике до вызова Выполнить(). Скопируйте текст в консоль запросов и проверьте там — так вы увидите ошибку сразу, без перезапуска всего алгоритма.

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

Консоль запросов — основной рабочий инструмент проверки. Скопируйте текст запроса из модуля, вставьте в консоль и задайте все параметры, которые заполняются в коде через УстановитьПараметр(). Критически важно задавать параметры теми же значениями и теми же типами, что и в реальном коде: дата 01.01.2026 и дата 01.01.2026 23:59:59 — разные значения, и отбор по документам за день даст разный результат.

Частая ситуация: в качестве параметра передаётся массив или список значений для условия В (&МассивСсылок). В консоли запросов такой параметр задаётся через специальный тип «Список значений» или «Массив» в зависимости от реализации обработки. Если передать одиночное значение вместо списка, запрос может вернуть пустой результат, и вы будете искать ошибку не там.

1. 1
   Скопируйте текст запроса из модуля в консоль запросов
2. 2
   Задайте все параметры значениями из реального сценария (через отладчик узнайте фактические значения)
3. 3
   Выполните запрос и посмотрите количество и содержимое строк
4. 4
   Уберите по одному условию ГДЕ, чтобы найти условие, отсекающее данные
5. 5
   Сравните результат с ожидаемым на контрольном документе, данные которого известны заранее

Как отладить запрос в конфигураторе

Установите точку останова на строке, где создаётся объект Запрос или заполняются параметры. Запустите отладку, выполните действие в предприятии, которое приводит к выполнению запроса, и дождитесь остановки. В табло (Shift+F9) вычислите значения всех параметров: убедитесь, что ссылки не пустые, даты заполнены, а массивы содержат элементы.

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

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

РезультатЗапроса = Запрос.Выполнить();
Если РезультатЗапроса.Пустой() Тогда
    Сообщить("Запрос не вернул данных. Проверьте параметры.");
КонецЕсли;
ТЗ = РезультатЗапроса.Выгрузить(); // смотрим в отладчике

Как проверить логику: соединения, итоги, виртуальные таблицы

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

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

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

Как проверить производительность запроса

Минимальная проверка — замер времени выполнения. В отладчике или через ТекущаяУниверсальнаяДатаВМиллисекундах() зафиксируйте время до и после Выполнить(). Запрос, который выполняется секунды на тестовой базе, на рабочей с миллионами записей может работать минутами, поэтому по возможности проверяйте на копии рабочей базы, а не на пустой.

Для клиент-серверных баз самый информативный метод — план запроса на СУБД. В MS SQL Server это делается через SQL Server Management Studio (Estimated/Actual Execution Plan), в PostgreSQL — через EXPLAIN ANALYZE. Тревожный признак — операции Scan (полное сканирование) по большим таблицам там, где ожидается Index Seek. Причина обычно в том, что отбор идёт по неиндексированному полю или над полем применена функция, которая отключает использование индекса.

Признаки медленного запроса на уровне языка запросов 1С: соединения по неиндексированным полям, отбор по виртуальным таблицам без параметров, вложенные запросы вместо временных таблиц, использование функции ПОДСТРОКА или ВЫРАЗИТЬ в условиях соединения. Переписывание таких конструкций часто даёт ускорение в разы без изменения логики.

Как проверить запрос в СКД и динамических списках

Запрос в схеме компоновки данных проверяется иначе: откройте схему в конструкторе, перейдите на закладку «Наборы данных» и выполните запрос отдельно от настроек отчёта. Если запрос в наборе корректен, а отчёт выводит не то — проблема в настройках СКД: отборах, группировках, ресурсах, а не в самом запросе.

Для динамических списков с произвольным запросом проверьте установку свойств «Основная таблица» и «Динамическое считывание данных». Неверно указанная основная таблица приводит к ошибкам при обновлении списка и к лишним соединениям, которые платформа добавляет автоматически. Текст итогового запроса, который реально уходит на сервер, можно увидеть в технологическом журнале по событию DBMSSQL/DBPOSTGRS — это помогает понять, как платформа трансформировала ваш запрос.

Часто задаваемые вопросы