Типы параметров в запросах 1С: от ТЕКУЩИЙ до ИСТИНА

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

Платформа 1С предоставляет мощный механизм типизации параметров прямо в тексте запроса. Использование ключевых слов ТЕКУЩИЙ, ЗНАЧЕНИЕ или ИСТИНА позволяет разработчику явно указать серверу, с чем именно предстоит работать: с данными из формы, с жестко заданной константой или с логическим флагом. Игнорирование этих нюансов приводит к тому, что база данных не может эффективно использовать индексы.

В этой статье мы детально разберем синтаксис объявления типов, различия между режимами компиляции и практические примеры их применения в реальных конфигурациях. Вы узнаете, как избежать типичных ошибок при передаче параметров и почему простой выбор между ТЕКУЩИЙ и ЗНАЧЕНИЕ может ускорить отчет в десятки раз.

Синтаксис объявления параметров в тексте запроса

Основной способ передачи данных в запрос 1С — это использование символа подстановки &. Однако сам по себе символ не говорит системе, какого типа данные придут. Для устранения неоднозначности используется конструкция, следующая сразу за именем параметра. Она заключает тип в круглые скобки и определяет стратегию обработки значения.

Самый распространенный сценарий — работа с полями формы или данными текущей записи. В этом случае используется модификатор ТЕКУЩИЙ. Он указывает компилятору, что тип параметра будет определен динамически на основе типа переменной в коде 1С в момент выполнения. Это наиболее гибкий вариант, но он имеет свои ограничения по производительности.

Если же вы передаете в запрос константу, например, фиксированную дату начала периода или идентификатор справочника, следует использовать модификатор ЗНАЧЕНИЕ. В этом случае тип параметра определяется на этапе компиляции запроса, что позволяет оптимизировать план выполнения. Синтаксически это выглядит как &Параметр(ЗНАЧЕНИЕ).

Однако в сложных запросах с соединениями или временными таблицами автоматическое определение может привести к ошибке «Неверный тип параметра». Явное указание типа — это признак качественного кода.

Различия между ТЕКУЩИЙ и ЗНАЧЕНИЕ

Понимание разницы между этими двумя модификаторами критически важно для производительности системы. Когда вы используете ТЕКУЩИЙ, платформа откладывает определение типа до момента фактического выполнения запроса. Это необходимо, когда значение параметра может меняться или когда оно берется из объекта с неопределенным типом.

В случае с ЗНАЧЕНИЕ происходит следующее: компилятор запроса «видит» конкретное значение и его тип заранее. Это позволяет механизму запросов 1С применить специфические оптимизации. Например, если вы передаете ссылку на элемент справочника как ЗНАЧЕНИЕ, сервер точно знает, что это ссылка, и может сразу использовать индекс по этому полю.

⚠️ Внимание: Использование ТЕКУЩИЙ для константных значений может привести к тому, что запрос будет выполняться как полноценный скан таблицы, игнорируя индексы, что критично для больших баз данных.

Рассмотрим пример. Если в запросе нужно отобрать документы за конкретный месяц, и дата передается как &ДатаНачала(ЗНАЧЕНИЕ), сервер построит план, учитывающий диапазон дат. Если же та же дата передана как ТЕКУЩИЙ, сервер может решить, что тип может измениться, и выбрать менее эффективный алгоритм выборки.

Также стоит отметить поведение с неопределенными значениями. Параметр с типом ТЕКУЩИЙ может принять значение Null (Неопределено) без ошибок синтаксиса, тогда как для ЗНАЧЕНИЕ тип должен быть конкретным. Это влияет на логику обработки пустых фильтров в отчетах.

Работа с булевыми параметрами и модификатором ИСТИНА

Особый интерес представляет модификатор ИСТИНА. Он используется преимущественно для передачи логических значений (Булево) в запрос. Это часто необходимо при реализации динамических условий, когда часть запроса должна выполняться только при определенном флаге.

Синтаксис &Флаг(ИСТИНА) гарантирует, что в параметр будет передано строго логическое значение. Это полезно в конструкциях типа ЕСЛИ &Флаг(ИСТИНА) ТОГДА.. ИНАЧЕ.. внутри текста запроса. Без явного указания типа компилятор может некорректно интерпретировать число 1 или 0 как логическое значение в некоторых контекстах.

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

ВЫБРАТЬ
Номенклатура.Наименование
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
(&ПоказыватьУдаленные(ИСТИНА) ИЛИ НЕ Номенклатура.ПометкаУдаления

В приведенном примере, если параметр &ПоказыватьУдаленные равен Истина, условие ИЛИ становится истинным для всех строк, и фильтр по пометке удаления игнорируется. Если Ложь, то условие работает штатно. Это мощный прием для гибкой фильтрации.

Оптимизация условий с ИСТИНА

При использовании булевых флагов в условиях ГДЕ, сервер 1С может не всегда оптимально упрощать выражение. В критичных по скорости отчетах лучше использовать два отдельных запроса или временные таблицы, если флаг меняет структуру выборки кардинально.

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

Рассмотрим реальную задачу: формирование отчета по продажам менеджера. У нас есть форма с параметрами: период, менеджер и флаг «Показывать все группы». Правильное описание параметров в запросе обеспечит быструю работу даже при миллионах записей в регистре продаж.

Первый параметр — период. Даты лучше передавать как ЗНАЧЕНИЕ, так как они являются константами на момент формирования отчета. Второй параметр — ссылка на сотрудника. Если пользователь выбрал конкретного менеджера, это тоже ЗНАЧЕНИЕ. Если выбрано «Все менеджеры», параметр может быть неопределен, и здесь уместен ТЕКУЩИЙ.

Параметр	Тип данных	Рекомендуемый модификатор	Причина выбора
ДатаНачала	Дата	ЗНАЧЕНИЕ	Константа, нужна оптимизация индексов
Менеджер	СправочникСсылка	ЗНАЧЕНИЕ / ТЕКУЩИЙ	Зависит от выбора «Конкретный» или «Все»
ВключатьЧерновики	Булево	ИСТИНА	Строгая типизация логического флага
ВалютаОтчета	СправочникСсылка	ЗНАЧЕНИЕ	Константа для пересчета сумм

При формировании объекта Запрос в коде 1С необходимо не только правильно написать текст, но и верно установить значения параметров. Ошибка возникает часто, когда в текст вставлено ЗНАЧЕНИЕ, а в код устанавливается переменная с несовместимым типом.

Пример установки параметров в коде:
Запрос.УстановитьПараметр("ДатаНачала", ДатаНачала);
Запрос.УстановитьПараметр("Менеджер", ВыбранныйМенеджер);

Обратите внимание, что метод УстановитьПараметр не требует указания типа, так как он уже определен в тексте запроса. Система сама проверит соответствие.

Частые ошибки и способы их устранения

Одна из самых распространенных ошибок — «Неверный тип параметра запроса». Она возникает, когда в тексте запроса указан тип, несовместимый с передаваемым значением. Например, вы объявили &Сумма(ЗНАЧЕНИЕ), подразумевая число, но передали строку или ссылку.

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

⚠️ Внимание: При копировании текста запроса из консоли запросов в код 1С часто теряются определения типов. Консоль может выполнять запрос без явных типов, используя контекст, а в модуле объекта это вызовет ошибку.

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

Если вы используете динамическое построение запроса (конкатенация строк), убедитесь, что подстановка параметров происходит корректно. Лучше использовать встроенные механизмы установки параметров, чем пытаться вставить значения прямо в текст запроса через кавычки — это не только опасно (SQL-инъекции), но и ломает механизм кэширования запросов.

Особенности работы в управляемых формах

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

При передаче реквизитов формы в запрос используйте ТЕКУЩИЙ, если тип поля может изменяться (например, универсальное поле поиска). Если же вы обращаетесь к конкретному реквизиту объекта данных, тип которого известен заранее, предпочтительнее ЗНАЧЕНИЕ для ускорения.

Особое внимание уделите параметрам, зависящим от настроек пользователя (Варианты отчета). Эти значения часто хранятся в виде сериализованных структур или сложных объектов. При передаче их в запрос может потребоваться предварительное преобразование к простому типу (число, строка, дата, ссылка).

Помните, что в тонком клиенте компиляция запроса происходит на стороне сервера. Ошибки в типах параметров будут выявлены только при обращении к серверу. Поэтому тестирование запросов с различными типами данных должно быть обязательным этапом разработки.

Можно ли изменить тип параметра после установки значения?

Нет, тип параметра определяется исключительно текстом запроса в момент его компиляции. Метод УстановитьПараметр лишь передает значение. Если тип значения не соответствует объявленному в тексте, возникнет ошибка выполнения.

Что будет, если не указать тип параметра вообще?

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

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

Для передачи списка используется специальный тип СписокЗначений. В тексте запроса тип параметра должен соответствовать этому типу, либо используется специальное условие В (&Список). Модификатор ЗНАЧЕНИЕ здесь также применим для оптимизации.

Влияет ли регистр букв в названии параметра?

Да, имена параметров в 1С чувствительны к регистру. &Дата и &дата — это разные параметры. Убедитесь, что имена в тексте запроса и в методе УстановитьПараметр совпадают посимвольно.