1с запрос необязательное условие

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1. Все ключевые слова языка запросов пишутся заглавными буквами.

Методическая рекомендация (полезный совет)

2. Рекомендуется указывать и необязательные конструкции запроса, прежде всего — явно назначать псевдонимы полям, в целях повышения наглядности текста запроса и «устойчивости» использующего его кода. Например, если в алгоритме используется запрос с полем, объявленным как

при изменении имени реквизита нужно будет также изменить и код, осуществляющий обращение по имени свойства Валюта к выборке из результата запроса. Если же поле будет объявлено как

Касса.Валюта КАК Валюта

то изменение имени реквизита приведет только к изменению текста запроса.

2а. Особенно внимательно следует относиться к автоматически присваиваемым псевдонимам для полей – реквизитов других полей, типа «. Касса.Валюта.Наименование. «. В приведенном выше примере поле получит автоматический псевдоним ВалютаНаименование , а не Наименование .

2б. Следует обязательно указывать ключевое слово КАК перед псевдонимом поля источника.

3. Текст запроса должен быть структурирован, не следует писать запрос в одну строку, даже короткий. Текст запроса должен быть нагляден, поскольку это существенно улучшает его понимание другими разработчиками.

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

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

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

6.1 При программной «сборке» текста запроса рекомендуется комментировать все этапы его сборки.

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

это позволяет осуществить экспресс-проверку корректности синтаксиса запроса
это упрощает разработку и сопровождение кода конфигурации, в том числе сторонними разработчиками

Типичные случаи программной модификации текста запроса

Изменение имени поля выборки или таблицы

«ВЫБРАТЬ
| Номенклатура.Наименование КАК Наименование ,
| Номенклатура. » + ИмяПоляКод + » КАК КодАртикул
|ИЗ
| Справочник.Номенклатура КАК Номенклатура»;

или аналогично для имени таблицы

или еще один вариант для имени таблицы

Если ИспользуетсяАдресноеХранение Тогда
ТекстЗапроса = СтрЗаменить(ТекстЗапроса , «#ТаблицаОстатков», «РегистрНакопления.ТоварыВЯчейках.Остатки»);
Иначе
ТекстЗапроса = СтрЗаменить(ТекстЗапроса , «#ТаблицаОстатков», «РегистрНакопления.ТоварыНаСкладах.Остатки»);
КонецЕсли;

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

Если ИспользоватьУпаковки Тогда

ТекстЗапроса = ТекстЗапроса +
«ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник. Номенклатура КАК Номенклатура»;

Если ИспользоватьУпаковки Тогда

«ВЫБРАТЬ
| Упаковки.Ссылка КАК Ссылка
|ИЗ
| Справочник.Упаковки КАК Упаковки»;

ТекстЗапроса = ТекстЗапроса +
«ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник.Номенклатура КАК Номенклатура»;

ТекстыЗапросовПакета = Новый Массив;

ТекстЗапроса =
«ВЫБРАТЬ
| Упаковки.Ссылка КАК Ссылка
|ИЗ
| Справочник.Упаковки КАК Упаковки»;

ТекстЗапроса =
«ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник.Номенклатура КАК Номенклатура «;

ТекстыЗапросовПакета.Добавить(ТекстЗапроса);
ТекстЗапроса = СтрСоединить(ТекстыЗапросовПакета, Разделитель);

В типовых конфигурациях обычно пишут так:

Я предлагаю писать более изящно:

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

Обычно такие вещи делают с помощью построителя отчета или запроса

TormozIT
Такое решение мне кажется наиболее отвечающим требованиям поставленной задачи.

acsent
Еще один вариант, для сложных условий

От Гения 1С : но лучше в варианте аскента писать так (это и програмисту понятнее)

От vhl :
А можно и не плодить параметры:

Этот принцип повсеместно используется в отчетах в конфе «Управление торговлей»

SuperSpade
Замечание по последнему варианту:
при сравнении с Неопределено в запросе предприятие ругается на сравнение несовместимых типов и типов
непостоянной длины, а вот с ЕСТЬ NULL работает:

СКД (Система Компоновки Данных) – это такая мощная хреновина в 1С с кучей непонятных кнопочек, используемая для интерактивного создания отчетов.

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

Колонка Использование=Авто/Всегда

Значение Авто – добавится галочка использованиея параметра. Но при этом, если убрать галочку и попытаться сформировать, то произойдет “Ошибка исполнения отчета”.

Чтобы избавиться от ошибки, в коде запроса надо взять в фигурные скобки условие отбора, в котором этот параметр используется (источник). Тогда, при незаполненном параметре условие с ним будет игнорироваться.

Но нельзя использовать в одних скобках условие с более чем одним параметром. Как быть? В условии виртуальной таблицы оставить условие с одним параметром в скобках, а остальные вынести в ГДЕ. Причем для каждого условия сделать отдельное ГДЕ, которое и взять в скобки.

Но!

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

Значение Всегда – параметр будет на форме без галочки.