Объектная модель запроса "Схема запроса" - теория и примеры использования
В 8.3.5 у нас появилась восможность программной работы с текстом запроса.
Новость об этом можно прочитать на сайте 1С "Управляемый конструктор запроса и объектная модель схемы запроса" .
Для анализа конкретного запроса рекоммендую "Дерево объектной модели схемы запроса".
Попробуем разобраться, что такое вообще запрос. В каком формате он представлен в 1С и на сервере ИБ.

Упрощенно можно выделить следующие уровни работы с запросом:
1. Запрос на языке СУБД. На этом уровне запрос представляет собой текстовую строку в синтаксисе конкретной СУБД.
Например "SELECT field1 FROM table1 WHERE table1.field2 > 100".
2. Драйвер конкретной СУБД. Это утилита, которая служит связующим звеном между программой и сервером. Она получает запрос от программы и передает его к СУБД.
На этом уровне 1С работает с внешними источниками данных.
3. Универсальный программный интерфейс. Это универсальный компонент, позволяющий программе получить доступ к данным в различных ИБ. Его также можно назвать менеджером драйверов. К нему в виде DSN подключаются используемые на компьютере драйвера конкретных СУБД. В зависимости от используемой системы тут может быть компонент ODBC, OLE DB, JDBC, ADO.NET либо любого другого стандарта. Судя по http://its.1c.ru/db/metod8dev#content:2926:1 на текущий момент 1С использует OLE DB. В платформе 7.7 использовался ODBC.
4. Объект на сервере 1С. На этом уровне выполняется работа сервера приложений с запросом.
Насколько я понимаю, в платформе на языке Си описан объект запроса для которого прописаны методы формирования текста SQL. С этим объектом запроса работают платформенные объекты (конструктор запросов, построитель и т.д.)
5. Запрос на языке 1С. На этом уровне запрос представляет из себя текст, написанный на псевдо-SQL-языке вида "ВЫБРАТЬ Справочник.ИмяСправочника.ИмяПоля ИЗ Справочник.ИмяСправочника"
Насколько я понимаю, с введением объекта "Схема запроса" ничего нового в платформе не изобрели.
Ранее мы могли работать только с текстовым представлением запроса (уровень 5). Это наиболее простой и понятный способ, хотя и не всегда удобный.
Сейчас нам дали доступ к объекту (уровень 4), с которыми ранее работали только платформенные механизмы.
Если проанализировать объект "Схема запросов", то его свойства очень четко пересекаются с конструктором запросов.
Каждому элементу и свойству можно найти визуальный аналог в конструкторе запросов.
Каждому клику в конструкторе можно подобрать аналогичную команду.
Например:
Закладка "Пакет запросов" = СхемаЗапроса.ПакетЗапросов;
Закладка "Таблицы и поля" = СхемаЗапроса.ПакетЗапросов[0].ДоступныеТаблицы;
Клик на таблице "Справочники" - "Номенклатура" = СхемаЗапроса.ПакетЗапросов[0].Операторы[0].Источники.Добавить("Справочник.Номенклатура");
Таким образом мы можем программно сформировать практически любой запрос, который можем сделать конструктором.
Разумеется, программное создание намного сложнее и длительнее, чем просто работа с конструктором или даже написание текста запроса вручную.
Для статических запросов, текст которых не изменяется, нет никакого смысла использовать схему.
Программная работа требует более глубокого понимания работы с запросами.
Она удобна в случае, если нам необходимо менять текст запроса динамически в зависимости от параметров системы, выбора пользователя, результата предыдущего запроса.
Для модификации текста имеющегося запроса, этот текст необходимо установить для схемы и получить обратно после модификации. Для этого используется код вида:
СхемаЗапроса = Новый СхемаЗапроса;
СхемаЗапроса.УстановитьТекстЗапроса(Запрос.Текст);
//Тут наши комманды модификации запроса
Запрос.Текст = СхемаЗапроса.ПолучитьТекстЗапроса();
Объектная модель запроса включает основной объект "Схема запроса" и около 50 связанных с ним подчиненных объектов, коллекций и специфичных типов данных. Поначалу ориентироваться в этом наборе объектов достаточно сложно.
Чтобы понять общую структуру схемы запроса открываем нужный раздел СП и загоняем все связи между объектами в графопостроитель.
Получается такой вот граф.
Не могу сказать, что он очень понятный, но общую идею отображает. Удобно подглядывать при анализе запроса.
В графе обозначены:
Желтым - объектные сущности схемы запроса;
Красным - коллекции объектов;
Зеленым - стандартные типы 1С (строка, число, булево);
Бирюзовым - примитивные типы, специфичные для схемы запроса;
Наиболее удобна схема запроса для модификаций готового запроса, на она также позволяет создать текст запроса с нуля.
Для примера рассмотрим создания с нуля пакета запроса, аналогичного запросу из "Справочной схемы"
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Товары.Ссылка КАК Номенклатура,
Закупки.Период КАК Период,
ЕСТЬNULL(Закупки.СуммаОборот, 0) КАК СуммаЗакупок,
0 КАК СуммаПродаж
ПОМЕСТИТЬ ТаблицаОбороты
ИЗ
Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Закупки.Обороты(&Начало, &Окончание, Месяц) КАК Закупки
ПО Закупки.Номенклатура = Товары.Ссылка
ГДЕ
НЕ Товары.ЭтоГруппа
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 100
Товары.Ссылка,
Продажи.Период,
0,
ЕСТЬNULL(Продажи.СуммаОборот, 0)
ИЗ
Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи.Обороты(&Начало, &Окончание, Месяц) КАК Продажи
ПО Продажи.Номенклатура = Товары.Ссылка
ГДЕ
НЕ Товары.ЭтоГруппа
ИНДЕКСИРОВАТЬ ПО
Номенклатура,
Период
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ТаблицаОбороты.Номенклатура КАК Номенклатура,
ТаблицаОбороты.Период КАК Период,
СУММА(ТаблицаОбороты.СуммаЗакупок) КАК СуммаЗакупок,
СУММА(ТаблицаОбороты.СуммаПродаж) КАК СуммаПродаж
ИЗ
ТаблицаОбороты КАК ТаблицаОбороты
СГРУППИРОВАТЬ ПО
ТаблицаОбороты.Номенклатура,
ТаблицаОбороты.Период
ИМЕЮЩИЕ
СУММА(ТаблицаОбороты.СуммаЗакупок) > 0
УПОРЯДОЧИТЬ ПО
ТаблицаОбороты.Номенклатура.Наименование,
Период
ИТОГИ
СУММА(СуммаЗакупок),
СУММА(СуммаПродаж)
ПО
ОБЩИЕ,
Номенклатура ТОЛЬКО ИЕРАРХИЯ
;
////////////////////////////////////////////////////////////////////////////////
УНИЧТОЖИТЬ ТаблицаОбороты
Проанализируем пакет запросов.
Пакет представляет из себя набор из трех запросов.
В первом запросе данные выбираются из ИБ двумя оперататорами (запросы по закупкам и продажам), каждый из которых использует два источника (справочник "Номенклатура" и соответствующий регистр накопления). Данные объединятся из двух операторов и помещаются во временную таблицу на сервере.
Во втором запросе мы получаем данные из временной таблицы, группируем их и получаем результат для обработки на сервере 1С.
Третий запрос служит для уничтожения временной таблицы, сформированной первым запросом.

Начнем программное создание пакета запросов.
Для разработки кода воспользуемся деревом запроса. По нему удобно определять пути к данным. Желательно периодически проверять получившийся текст запроса после модификаций кода.
Для начала создадим объект "СхемаЗапроса".
СхемаЗапроса = Новый СхемаЗапроса;
Созданная схема запроса уже содержит один пакет и один оператор выбора.
Для удобства работы сохраним их в отдельные переменные.
ЗапросВыбораИзИБ = СхемаЗапроса.ПакетЗапросов[0];
ОператорВыбораЗакупок = ЗапросВыбораИзИБ.Операторы[0];
Добавляем источники в первый оператор выбора.
Для этого используем метод коллекции источников "Добавить()". В параметрах метода указываем имя добавляемой таблицы ее псевдоним, по которму будем обращаться к ней в дальнейшем.
В качестве добавляемсой таблицы можно использовать либо имя таблицы, либо ссылку на неё в коллекции доступных таблиц.
ИсточникНоменклатура = ОператорВыбораЗакупок.Источники.Добавить("Справочник.Номенклатура","Товары");
ИсточникЗакупки = ОператорВыбораЗакупок.Источники.Добавить("РегистрНакопления.Закупки.Обороты","Закупки");
По умолчанию второй источник добавляется с левым соединение к первому.
Нам нужно обратное сединение. Меняем тип соединения.
ИсточникЗакупки.Соединения[0].ТипСоединения = ТипСоединенияСхемыЗапроса.ПравоеВнешнее;
Параметры таблиц:
Для каждой добавленной в качестве источника таблицы мы можем задать дополнительные параметры.
Коллекция параметров заполняется автоматически при добавлении таблицы в зависимости от типа таблицы.
Добавить в неё параметр вручную нельзя, можно лишь установить значение имеющегося параметра.
Таблица "Справочник.Номенклатура" это простая таблица справочника. У нее параметров нет.
Таблица "РегистрНакопления.Закупки.Обороты" это таблица оборотов регистра накопления.
Согласно СП, у неё есть 4 параметра: начало периода, конец периода, периодичность, условие.
Нам необходимо установить первые 3 параметра:
ИсточникЗакупки.Источник.Параметры[0].Выражение = Новый ВыражениеСхемыЗапроса("&Начало") ;
ИсточникЗакупки.Источник.Параметры[1].Выражение = Новый ВыражениеСхемыЗапроса("&Окончание") ;
ИсточникЗакупки.Источник.Параметры[2].Выражение = Новый ВыражениеСхемыЗапроса("Месяц") ;
Укажем колонки, которые необходимо выбрать из перечисленных таблиц.
Для этого добавляем поля в коллекцию выбираемых полей оператора выбора.
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("Товары.Ссылка");
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("Закупки.Период");
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("ЕСТЬNULL(Закупки.СуммаОборот, 0)");
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("0");
Укажем на уровне запроса вцелом псевдонимы для выбираемых колонок:
Обратите внимание, что колонки таблиц выбираем для каждого подзапроса объединения, имена колонкам присваиваем вцелом для коллекции "Колонки" на уровне запроса пакета.
ЗапросВыбораИзВТ.Колонки[0].Псевдоним = "Номенклатура";
ЗапросВыбораИзВТ.Колонки[1].Псевдоним = "Период";
ЗапросВыбораИзВТ.Колонки[2].Псевдоним = "СуммаЗакупок";
ЗапросВыбораИзВТ.Колонки[3].Псевдоним = "СуммаПродаж";
Добавим условие на выбор данных
ОператорВыбораПродаж.Отбор.Добавить("НЕ Товары.ЭтоГруппа");
Всё аналогично добавляем для второй части запроса.
Сопоставление колонок:
У нас в каждом операторе выбора выбирается 4 поля (элемент справочника "Номенклатура", дата и два числовых поля).
При объединении колонок из двух операторов выбора колонки из справочника и даты система соспоставит сама.
Числовых колонок две. Схема может самостоятельно сопоставить их с колонками первого запроса неверно.
Указываем, какой колонке таблицы результата какое выражение соответствует.
ЗапросВыбораИзИБ.Колонки[2].Поля.Установить(1,ВыражениеЗакупки);
ЗапросВыбораИзИБ.Колонки[3].Поля.Установить(1,ВыражениеПродажи);
Все аналогично повторяем для второго запроса пакета.
Из отличий, тут используется отбор по итоговым значения вида "ИМЕЮЩИЕ".
Такое условие добавляется аналогично обычному отбору на детальные записи.
Схема сама определит, в какой раздел условий поместить наше в зависимости от использования функций группировки.
ОператорВыбрать.Отбор.Добавить("СУММА(ТаблицаОбороты.СуммаЗакупок) > 0");
Последним шагом добавляем запрос на уничтожение таблицы данных
ЗапросУничтоженияВТ = СхемаЗапроса.ПакетЗапросов.Добавить(Тип("ЗапросУничтоженияТаблицыСхемыЗапроса"));
ЗапросУничтоженияВТ.ИмяТаблицы = "ТаблицаОбороты";
А также выставляем дополнительные свойства запросов:
ЗапросВыбораИзИБ.ТаблицаДляПомещения = "ТаблицаОбороты";
ЗапросВыбораИзИБ.ВыбиратьРазрешенные = Истина;
Итоговый полный вариант формирования запроса:
//Создание схемы запроса
СхемаЗапроса = Новый СхемаЗапроса;
ЗапросВыбораИзИБ = СхемаЗапроса.ПакетЗапросов[0];
//Установка свойств запроса
ЗапросВыбораИзИБ.ТаблицаДляПомещения = "ТаблицаОбороты";
ЗапросВыбораИзИБ.ВыбиратьРазрешенные = Истина;
//Добавляем операторы выбора первого запроса пакета
ОператорВыбораЗакупок = ЗапросВыбораИзИБ.Операторы[0];
ИсточникНоменклатура = ОператорВыбораЗакупок.Источники.Добавить("Справочник.Номенклатура","Товары");
//Добавляем запрос выбора из регистра закупок
ИсточникЗакупки = ОператорВыбораЗакупок.Источники.Добавить("РегистрНакопления.Закупки.Обороты","Закупки");
ИсточникЗакупки.Источник.Параметры[0].Выражение = Новый ВыражениеСхемыЗапроса("&Начало") ;
ИсточникЗакупки.Источник.Параметры[1].Выражение = Новый ВыражениеСхемыЗапроса("&Окончание") ;
ИсточникЗакупки.Источник.Параметры[2].Выражение = Новый ВыражениеСхемыЗапроса("Месяц") ;
//Меняем тип соединения
ИсточникЗакупки.Соединения[0].ТипСоединения = ТипСоединенияСхемыЗапроса.ПравоеВнешнее;
//Указываем выбираемые поля
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("Товары.Ссылка");
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("Закупки.Период");
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("ЕСТЬNULL(Закупки.СуммаОборот, 0)");
ОператорВыбораЗакупок.ВыбираемыеПоля.Добавить("0");
//Указываем спевдонимы для выбранных полей
ЗапросВыбораИзИБ.Колонки[0].Псевдоним = "Номенклатура";
ЗапросВыбораИзИБ.Колонки[1].Псевдоним = "Период";
ЗапросВыбораИзИБ.Колонки[2].Псевдоним = "СуммаЗакупок";
ЗапросВыбораИзИБ.Колонки[3].Псевдоним = "СуммаПродаж";
//Добавляем отбор
ОператорВыбораЗакупок.Отбор.Добавить("НЕ Товары.ЭтоГруппа");
///////////////////////
//Выбираем данные о продажах
ОператорВыбораПродаж = ЗапросВыбораИзИБ.Операторы.Добавить();
ИсточникНоменклатура = ОператорВыбораПродаж.Источники.Добавить("Справочник.Номенклатура","Товары");
ОператорВыбораПродаж.ВыбираемыеПоля.Добавить("Товары.Ссылка");
//Добавляем источник РН и устанавливаем параметры
ИсточникПродажи =ОператорВыбораПродаж.Источники.Добавить("РегистрНакопления.Продажи.Обороты","Продажи");
ИсточникПродажи.Источник.Параметры[0].Выражение = Новый ВыражениеСхемыЗапроса("&Начало") ;
ИсточникПродажи.Источник.Параметры[1].Выражение = Новый ВыражениеСхемыЗапроса("&Окончание") ;
ИсточникПродажи.Источник.Параметры[2].Выражение = Новый ВыражениеСхемыЗапроса("Месяц") ;
ИсточникПродажи.Соединения[0].ТипСоединения = ТипСоединенияСхемыЗапроса.ПравоеВнешнее;
//Указываем отбираемые поля и устанавливаем для числовых полей соответствие с полями первого запроса
ОператорВыбораПродаж.ВыбираемыеПоля.Добавить("Продажи.Период");
ВыражениеЗакупки = ОператорВыбораПродаж.ВыбираемыеПоля.Добавить("0");
ВыражениеПродажи = ОператорВыбораПродаж.ВыбираемыеПоля.Добавить("ЕСТЬNULL(Продажи.СуммаОборот, 0)");
ЗапросВыбораИзИБ.Колонки[2].Поля.Установить(1,ВыражениеЗакупки);
ЗапросВыбораИзИБ.Колонки[3].Поля.Установить(1,ВыражениеПродажи);
//Добавляем отбор
ОператорВыбораПродаж.Отбор.Добавить("НЕ Товары.ЭтоГруппа");
//Индексируем данные
ЗапросВыбораИзИБ.Индекс.Добавить(ЗапросВыбораИзИБ.Колонки[0]);
ЗапросВыбораИзИБ.Индекс.Добавить(ЗапросВыбораИзИБ.Колонки[1]);
//Устанавливаем параметры выбора данных
ОператорВыбораПродаж.ВыбиратьРазличные = Истина;
ОператорВыбораПродаж.КоличествоПолучаемыхЗаписей = 100;
////////////////
//Второй пакет запроса
ЗапросВыбораИзВТ = СхемаЗапроса.ПакетЗапросов.Добавить();
ОператорВыбрать = ЗапросВыбораИзВТ.Операторы[0];
//Устанавливаем сформированную в прошлом запросе временную таблицу как источник
Источник = ОператорВыбрать.Источники.Добавить("ТаблицаОбороты","ТаблицаОбороты");
ОператорВыбрать.ВыбираемыеПоля.Добавить("ТаблицаОбороты.Номенклатура");
ОператорВыбрать.ВыбираемыеПоля.Добавить("ТаблицаОбороты.Период");
ОператорВыбрать.ВыбираемыеПоля.Добавить("СУММА(ТаблицаОбороты.СуммаЗакупок)");
ОператорВыбрать.ВыбираемыеПоля.Добавить("СУММА(ТаблицаОбороты.СуммаПродаж)");
//Условие отбора
ОператорВыбрать.Отбор.Добавить("СУММА(ТаблицаОбороты.СуммаЗакупок) > 0");
//Устанавливаем псевдонимы колонок
ЗапросВыбораИзВТ.Колонки[0].Псевдоним = "Номенклатура";
ЗапросВыбораИзВТ.Колонки[1].Псевдоним = "Период";
ЗапросВыбораИзВТ.Колонки[2].Псевдоним = "СуммаЗакупок";
ЗапросВыбораИзВТ.Колонки[3].Псевдоним = "СуммаПродаж";
//Порядок сортировки данных
ЗапросВыбораИзВТ.Порядок.Добавить(ЗапросВыбораИзВТ.Операторы[0].Источники[0].Источник.ДоступныеПоля[0].Поля[6]);
ЗапросВыбораИзВТ.Порядок.Добавить(ЗапросВыбораИзВТ.Колонки[1]);
//Итоги запроса
ИтогНоменклатура = ЗапросВыбораИзВТ.КонтрольныеТочкиИтогов.Добавить(ЗапросВыбораИзВТ.Колонки[0]);
ИтогНоменклатура.ТипКонтрольнойТочки = ТипКонтрольнойТочкиСхемыЗапроса.ТолькоИерархия;
ЗапросВыбораИзВТ.ОбщиеИтоги =Истина;
ЗапросВыбораИзВТ.ВыраженияИтогов.Добавить(ЗапросВыбораИзВТ.Колонки[2]);
ЗапросВыбораИзВТ.ВыраженияИтогов.Добавить(ЗапросВыбораИзВТ.Колонки[3]);
////////////////
//Последний запрос пакета - удаление временной таблицы
ЗапросУничтоженияВТ = СхемаЗапроса.ПакетЗапросов.Добавить(Тип("ЗапросУничтоженияТаблицыСхемыЗапроса"));
ЗапросУничтоженияВТ.ИмяТаблицы = "ТаблицаОбороты";
Выполнив этот набор команд мы получаем тот же запрос, который ранее получили конструктором.
Явно видно, что программное создание гораздо сложнее, чем текстовое.
Возникает вопрос, в чем смылс морочиться с программным создание вместо удобного конструирования.
Если этот запрос больше не изменится, то смысла нет никакого.
Плюшки появляются только в случае, если нам необходимо этот запрос модифицировать дальше в зависимости от настроек.
Рассмотрим несколько примеров модификация нашего пакета из 3х запросов:
Пример 1.
Допустим, у нас есть переменные "Организация" и "Склад". И в случае, если они заполнены, нам необходимо добавить в отбор данных условия на эти переменные.
При работе с текстом нам придется вклиниваться в текст запроса и писать сложное условия вида "Если заполнен скалад, то добавить условие". при чем разрывать в нескольких местах и комбинировать варианты заполнены и склад и организация, заполнен только склад, заполнена только организация, ничего не заполнено.
После такой модификации открыть запрос конструктором будет и невозможно и дальнейшая его модификация сильно затруднена.
При программной работе с данными мы просто добавляем команды:
Если ЗначениеЗаполнено(Организация) Тогда
ОператорВыбораЗакупок.Отбор.Добавить("Закупки.Организация = &Организация");
ОператорВыбораПродаж.Отбор.Добавить("Продажи.Организация = &Организация");
КонецЕсли;
Если ЗначениеЗаполнено(Склад) Тогда
ОператорВыбораЗакупок.Отбор.Добавить("Закупки.Склад = &Склад");
ОператорВыбораПродаж.Отбор.Добавить("Продажи.Склад = &Склад");
КонецЕсли;
Пример 2.
Нам нужно отобрать товары, для которых последняя цена выше 1000руб.
Т.е. необходимо
1. Добавить в текст запроса выбор во временную таблицу из регистра цен номенклатуры, по которой цены выше 1000руб.
2. Добавить при выборе данных условия по этой временной таблице в оба запроса выбора данных (закупки и продажи).
Как вклиниваться в текстовый запрос для выполнения этих действий, вы пожете представить самостоятельно.
Программно мы просто добавляем строки кода:
//Добавляем временную таблицу
ЗапросИзРегистраЦен = СхемаЗапроса.ПакетЗапросов.Добавить();
//Настраиваем временную таблицу
ЗапросИзРегистраЦен.ТаблицаДляПомещения = "ВТ_ЦеныНоменклатуры";
ОператорВыбрать = ЗапросИзРегистраЦен.Операторы[0];
Источник = ОператорВыбрать.Источники.Добавить("РегистрСведений.ЦеныНоменклатуры.СрезПоследних","ЦеныНоменклатурыСрезПоследних");
ОператорВыбрать.ВыбираемыеПоля.Добавить("ЦеныНоменклатурыСрезПоследних.Номенклатура");
ОператорВыбрать.Отбор.Добавить("ЦеныНоменклатурыСрезПоследних.Цена > &Цена");
//Сдвигаем новую табличку перед запросами выбора данных
СхемаЗапроса.ПакетЗапросов.Сдвинуть(СхемаЗапроса.ПакетЗапросов.Индекс(ЗапросИзРегистраЦен),0);
//Добавляем условия в исходные запросы
ОператорВыбораЗакупок.Отбор.Добавить("Закупки.Номенклатура В (ВЫБРАТЬ ВТ_ЦеныНоменклатуры.Номенклатура ИЗ ВТ_ЦеныНоменклатуры КАК ВТ_ЦеныНоменклатуры)");
ОператорВыбораПродаж.Отбор.Добавить("Продажи.Номенклатура В (ВЫБРАТЬ ВТ_ЦеныНоменклатуры.Номенклатура ИЗ ВТ_ЦеныНоменклатуры КАК ВТ_ЦеныНоменклатуры)");
ИМХО, даже для этих примеров программная работа с запросом удобнее, чем прямая работа с текстом.
При этом учтем, что данные варианты модификаций все-таки достаточно простые.
С усложнением вариантов модификаций, увеличением количества запросов в пакете, выбором различных модификаций в зависимости от условий (например, добавление условий либо по регистру цен, либо по видам номенклатуры, либо по планам производства) программная работа выглядит всё более удобной по сравнению с работой с текстовой строкой.
Попрактиковаться с запросами можно с использованием обработки Дерево объектной модели схемы запроса.Она удобна для разработки комманд модификации имеющегося запроса. В ней же есть несколько примеров модификации кода запроса и граф схемы типов запроса.
з.ы. Всё выше написанное всего лишь моё личное понимание темы. Возможно, где-то ошибаюсь. Комментарии и уточнения приветствуются.
upd: Еще один небольшой пример использования схемы запроса. Формирование запроса, выполняющего поиск задвоенных значений предопределенных данных. Без обращения к метаданным формирует один общий запрос ко всем справочникам, планам счетов, ПВХ, ПВР вцелом по конфигурации. Используется в обработке Установка, просмотр и поиск задвоенных предопределенных значений справочников, планов счетов, ПВХ, ПВР.
СхемаЗапроса = Новый СхемаЗапроса;
КоллекцияОператоры = СхемаЗапроса.ПакетЗапросов[0].Операторы;
Для каждого ГруппаТаблиц Из СхемаЗапроса.ПакетЗапросов[0].ДоступныеТаблицы Цикл
Если ГруппаТаблиц.Представление = "Справочники"
ИЛИ ГруппаТаблиц.Представление = "ПланыСчетов"
ИЛИ ГруппаТаблиц.Представление = "ПланыВидовРасчета"
ИЛИ ГруппаТаблиц.Представление = "ПланыВидовХарактеристик" Тогда
Для каждого Таблица Из ГруппаТаблиц.Состав Цикл
Для каждого ПолеТаблицы Из Таблица.Поля Цикл
Если ПолеТаблицы.Имя = "ИмяПредопределенныхДанных" Тогда
НовыйОператор = КоллекцияОператоры.Добавить();
НовыйИсточник = НовыйОператор.Источники.Добавить(Таблица,"СправочникИмя");
НовыйОператор.ВыбираемыеПоля.Добавить(""""+Таблица.Имя+"""");
НовыйОператор.ВыбираемыеПоля.Добавить("КОЛИЧЕСТВО(РАЗЛИЧНЫЕ СправочникИмя.ИмяПредопределенныхДанных)" );
НовыйОператор.Группировка.Добавить("СправочникИмя.ИмяПредопределенныхДанных");
НовыйОператор.Отбор.Добавить("СправочникИмя.Предопределенный");
НовыйОператор.Отбор.Добавить("КОЛИЧЕСТВО(РАЗЛИЧНЫЕ СправочникИмя.Ссылка) > 1");
Продолжить;
КонецЕсли;
КонецЦикла;
КонецЦикла;
КонецЕсли;
КонецЦикла;
ТОП-6 инструментов для разработчика 1С
Подборка лучших инструментов для разработчика 1С включает Toolkit, DCT, OneDebugger, PrintWizard, DataFormWizard и Infostart MCP. Любой инструмент со скидкой 20% при покупке от двух решений.
Вступайте в нашу телеграмм-группу Инфостарт
схема запроса объектная модель запроса запрос модификация запроса
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструментарий разработчика Роли и права Запросы СКД Разработчик Руководитель проекта 1С:Предприятие 8 Платные (руб)
Инструменты для разработчиков 1С 8.3 и 8.5: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.
16500 руб.
02.09.2020 285464 1606 423
Инструментарий разработчика Запросы Разработчик 1С 8.3 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)
Структура запроса. Обработка визуально показывает, из какого количества подзапросов состоит запрос.
2 стартмани
06.07.2026 4921 65 XSlava 20
Запросы Разработчик 1С 8.3 Россия Бесплатно (free)
Визуальный «Конструктор запроса» 1С, встроенный прямо в VS Code, — аналог конструктора из Конфигуратора и EDT, но без запуска платформы. Расширение читает конфигурацию, выгруженную в файлы, позволяет собрать запрос мышью и генерирует корректный текст на языке запросов 1С (SDBL). Открывает уже существующий текст запроса из кода для правки и — что особенно ценно — сохраняет комментарии при цикле «открыть - править - сохранить». Подходит тем, кто пишет код 1С в VS Code, держит под рукой множество проектов и не хочет ради одного запроса запускать тяжёлый Конфигуратор или EDT.
26.06.2026 10642 Alex_YAM 7
Нейросети Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 Абонемент ($m)
Консоль запросов 1.0: добавлен ИИ-помощник (запрос в DeepSeek), который помогает быстрее получать каркас Запроса 1С Сформулируйте простое описание; нажмите кнопку – получите результат прямо в консоли. Где дальше его можно дорабатывать и тестировать. 28.5.2026 Добавил "Консоль запросов 2.0" (запрос в DeepSeek + Claude) 4.10.2026 Обновил "Консоль запросов 2.0"
3 стартмани
20.05.2026 9547 46 German4739 72
WEB-интеграция Запросы Разработчик 1С 8.3 Абонемент ($m)
Post1C - это внешняя обработка, которая превращает 1С в полноценный инструмент для тестирования REST API. Всё управление сосредоточено в одном окне: настройка запроса, выполнение, просмотр ответа и генерация кода - без переключения между формами. Аналог Postman, но работающий в привычной среде 1С.
1 стартмани
02.04.2026 4630 105 priem_nv 27
Запросы Механизмы типовых конфигураций Разработчик 1С:Предприятие 8 1С:Управление торговлей 11 Россия Бесплатно (free)
Предлагается обзор работы с объектной моделью запроса по схемам запросов типовым функционалом УТ 11.5.
09.10.2025 13380 aximo 18
Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)
QueryConsole1C — расширение, включающее консоль запросов с поддержкой исполняемых представлений — аналогов виртуальных таблиц, основанных на методах программного интерфейса ЗУП. Оно позволяет выполнять запросы с учётом встроенной бизнес-логики, отлаживать алгоритмы получения данных и автоматически генерировать код на встроенном языке 1С.
1 стартмани
16.05.2025 13642 168 zup_dev 32
Инструментарий разработчика Запросы Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Абонемент ($m)
В данной публикации рассказывается о решении, которое позволяет находить сразу все ошибки в тексте запроса за раз, а не только самую первую.
2 стартмани
05.03.2025 7705 25 XilDen 12
Через менеджер запроса текст не наращивается.
Менеджером можно объединить несколько отдельных запросов или пакетов, чтобы они использовали одни и те же временные таблицы.
При формировании запросов, связанных одним менеджером, мы не видим в конструкторе таблиц, связанных с этим менеджером в других запросах.
Очень часто писатели конфигураций используют менеджер временных таблиц для динамического построения одного запроса.
Просто запросы пакета разбросаны по всей конфигурации.
А часто во время отладки хочется понять в каком запросе нужно изменение внести или ошибку найти.
приходится ползать по всем модулям вслед за отладчиком и копипастом в консоли выстраивать весь огромный запрос. Дальше уже с ним баловаться.
Гораздо полезнее было бы реализовать просмотр содержимого Менеджера ВТ - и результата и текста запроса.
А так эта новая фишка делает нечитаемый код динамического запроса еще более нечитаемым.
Может это привыкнуть надо.
МенеджерВременныхТаблиц.Таблицы[2].ПолучитьДанные().Выгрузить()Где "2" индекс таблицы из всех таблиц менеджера.
А так схема запросов очень удобная вещь, если требуется генерить запрос с множеством вариаций возвращаемых данных.
Жили мы без этой фичи множество времени и дальше проживём. Выморочная вещь, для галочки сделанная.
Вы что, всерьёз верите, что изменять или хотя бы понимать запрос станет проще? Ни разу. Вот увидите, как писатели типовых конф, получив сей инструмент, превратят один ранее заданный куском запрос в нечто, собираемое десятью процедурами, и понять что-то станет ещё тяжелее.
(1) Присоединяюсь к вопросу.
Запросы, связанные через менеджер, это разные запросы, работающие с общими временными таблицами.
Насколько я понимаю, через схему запроса мы не можем получить доступ к тексту другого запроса, использующего этот же менеджер.
(9) caponid, собственно, стандартный конструктор запросов это и есть визуальный интерфейс к объекту "Схема запроса". Он выводит все свойства объекта и через него мы можем визуально их просматривать и править.
Чего в нём еще не хватает?
Чего в нём еще не хватает?
Собственно, один вариант уже есть. Сегодня видела на инфостарте обработку конвертер. Правда, пока не совсем рабочий.
Пока не вижу реального применения такой автогенерации.
1. в запросе условие:
|ГДЕ
| ВЫБОР
| КОГДА &ИспользованиеОтбораСклад
| ТОГДА СправочникСклады.Ссылка = &Склад
| ИНАЧЕ ИСТИНА
| КОНЕЦ2. параметры запроса:
Запрос.УстановитьПараметр("ИспользованиеОтбораСклад", ЗначениеЗаполнено(Склад));
Запрос.УстановитьПараметр("Склад", Склад);выглядит читабельней, как мне кажется. И запрос "рвать" не надо - все прекрасно отрывается в конструкторе.
но тема интересная - надо покопаться на досуге.
Они подробно описаны тут
Они хороши, когда мы говорим об 1-2х изменениях.
Но каждая такая модификация все-таки усложняет понимание кода и часто немного замедляет выполнение запроса.
Чем сложнее запрос, тем менее допустимы такие вещи.
В варианте
ГДЕ СправочникСклады.Ссылка = &Склад ИЛИ НЕ &ИспользованиеОтбораСкладхоть и используется ИЛИ, но вторая часть условия содержит простое значение и индекс все равно используется.
Можете проверить план запроса.
как пример
СхемаЗапроса = Новый СхемаЗапроса;
Пакет = СхемаЗапроса.ПакетЗапросов[0];
Оператор = Пакет.Операторы[0];
ИмяТаблицыЗапроса = Пакет.ДоступныеТаблицы.Найти(Источник.Метаданные().ПолноеИмя());
ТаблицаЗапроса = Оператор.Источники.Добавить(ИмяТаблицыЗапроса);
ТаблицаЗапроса.Источник.Псевдоним = "ТаблицаЗапроса";
Для каждого запись Из Структура Цикл
Если Запись.Значение <> Неопределено Тогда
стр = СписокСкладов.Добавить(); стр.Склад = запись.Значение;
Оператор.ВыбираемыеПоля.Добавить(запись.Ключ);
КонецЕсли;
КонецЦикла;
Оператор.Отбор.Добавить("ТаблицаЗапроса.Ссылка = &Ссылка");
Запрос = Новый Запрос;
Запрос.Текст = СхемаЗапроса.ПолучитьТекстЗапроса();
Запрос.Параметры.Вставить("Ссылка", Источник.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
ПоказатьВ структуре список реквизитов, которые надо выбрать - используется что бы проверить на изменение реквизитов по сравнению с сохраненными в базе
Есть инструменты, которые позволяют что - то упростить, что то сделать (как сделано в типовых - сложить или заменить вставкой/заменой текста) иначе , или для "гиков" вообще через "что то с чем-то" - а то что предложили - это всего лишь тоже инструмент - а пользоваться или нет - это Вы сами решите для себя - я выбор сделал (все реально работает и позволило исключить навскидку 30-50% лишнего кода - вот тут (7)) - и по этому поводу "что это не тру" оправдываться не буду.
- внесение точечных модификаций в тексты запросов поставщика для облегчения обновления конфигурации от поставщика
- полные/частичные генераторы текстов запросов
- визуальные средства разработки запросов
никогда так не делайте!!!
расскажу почему:
был запрос
Вы его поменяли этим чудом
Вышел новый релиз и запрос поменялся
Вы при тройном сравнении увидели свои новые строчки, и скопировали их
А в запросе изменился кто-то
Ваши строчки кода модифицируют не те поля и не так, причем, не факт, что будет ошибка и возможно все продолжит работать, но не так как надо.
Можно напороться на семантическую ошибку, программа работает без сбоев, но результаты получаются неверные
Есть мнение, что у этого механизма плюсов просто нет. Никаких. Именно это и пытается донести не восторженная часть сообщества.
А подходом "Просто им нужно уметь пользоваться", ну давайте на ассемблере теперь писать и с базой работать. Сплошные плюсы - контроль полный, производительность сумасшедшая, просто "пользоваться надо уметь".
И что? Каждому инструменту своё место. Не нужно микроскопом гвозди забивать. 1С был удобен для быстрой и комфортной разработки учётных программ. А сейчас он по своей громоздкости начинает приближаться к языкам высокого уровня. Скоро будет возникать вопрос, а зачем мне писать программу на 1С, если я тоже самое могу сделать на нормальном языке с нормальной объектной моделью без различных ограничений, накладываемых платформой 1С? У 1С в голове беда - она всё время пытается объять необъятное.
программно формировать таким образом запросы - это как программно формировать СКД - можно, но зачем?
трудозатраты на такую работу будут космические при сомнительного рода полезности
имхо, это полезно там, где возникает задача парсинга текста запросов - визуальные рендеры, построения моделей и прочего всего подобного
Следующий вопрос: на каком принципе можно получить связи запроса для построения графа?
Просто учитываем, что есть такая возможность и со временем её начнут использовать в типовых.
По поводу графа.
Просто выписываем из СП, какие у объектов есть свойства и какие типы данных допустимы для этих свойств.
Потом просто в текстовом виде связи скармливаем связи графопостроителю. Он уже размещает элементы на листе.
Автоматического определения нет.
Я выписывала для себя в Ексель для этой обработки
В ней же выложен приложением исходный текст для графопостроителя и ссылка на него.
(15) Makushimo, Через схему, к сожалению, такое сделать нельзя. Так как она сейчас все-таки строится на основании текста запроса. Менеджер, грубо говоря, всего лишь связывает запросы в одно пространство, чтобы они использовали общие данные. Но запросы остаются отдельными запросами.
(16) iTony73, Да, мне оже кажется, что схема более применима для модификаций имеющегося запроса, а не для создания с нуля. Вроде эту мысль в статье высказывала.
Поэтому я думаю рано или поздно это будет реализовано.
То есть, можно сначала написать, большой запрос Конструктором. Затем загнать его в Схему, и уже там работать с теми вещами, которые необходимо Алгоритмизировать; Очень крутая штука, не удивлюсь, если через год, это станет стандартом, для программной работы над Запросами!
Разработчики давно наловчились динамически делать и менять непосредственно текст запроса, так что вряд ли оно получит широкое применение для того, чтобы что-нибудь изощренно спросить у базы.
Зато в качестве парсера текста запроса (если я правильно понял) вещь незаменимая. Ты ему строку, а он тебе в объект разложил. Красота!
Но зачем это может быть нужно? Сходу не соображу. Писать автоматические переводчики с языка запросов 1С на другой язык? На какой?
Новая супер-консоль запросов, которая более корректно и точно представляет запрос в виде дерева и имеет дополнительные плюшки-навороты? Может быть.
Где еще может быть нужно распрасить текст запроса?
Писать свой конструктор смысла не вижу. Типовой, на мой взгляд, достаточно удобен. Не думаю, что можно написать на УФ его лучше, чем программисты платформы написали на Си.
ОператорВыбораПродаж.Отбор.Добавить("НЕ Товары.ЭтоГруппа");и
ТестЗапроса = ТекстЗапроса + "НЕ Товары.ЭтоГруппа";Что касается типового конструктора. Да, удобен. Но посмотрите консоль запросов в инструментах разработчика. Отличная вещь.
Непосредственно конструктор там используется стандартный. Но кое-какая работа с текстом запроса идет.
1. Если мы добавляем условия в имеющийся запрос, то с программным добавлением текст исходного запроса не разрывается и его можно открыть конструктором.
2. Эти два варианта примерно эквивалентны, если мы говорим о добавлении одного условия. Если их десяток (по складу, организации, подразделению, номенклатуре....) и нужно добавить лишь несколько из этого десятка, в зависимости от условий, то програмное добавление удобнее.
3. Схема удобнее, если нужно удалить условия или поля. При любой модификации она остается синтаксически корректной. Например, если мы удаляем колонку, то она автоматически удалится и в выбранных полях и в итогах и в группировках. Вклиниванием в текст пришлось бы вклиниваться в несколько мест.
Разумеется, во многих случаях стандартные варианты удобнее. Я просто предлагаю еще один вариант работы.
Инструментами разработчика пользуюсь, но реально использую очень небольшой набор функционала. Хотя вещь великолепная. Заменяет набор различных обработок.
А дерево запроса заточено на анализ и отладку, т.е. на работу со всеми блоками текста запроса, которые можно выполнять отдельно.
Собственно об этом и говорю. Запрос разбирается в объектную модель, чтобы предоставить больше возможности для представления разработчику и отладки по-частям.
А как он разбирается? Схемой запроса?
Нужно добавить новое поле.
Если использовать традиционное "склеивание", то это нужно "хардкодить" запрос. А если в следующем релизе его изменят? Добавят условие, соединение с таблицей или сортировку?
Нужно будет заново хардкодить новый запрос.
К тому же проблематичнее обновляться. Уже давно пришел к выводу, что изменения на форме лучше делать программно. Добавлять, удалять, изменять элементы формы. Также и с динамическими списками. Запрос типовой мы не изменяем. Просто его модифицируем программно. При обновлении видим, что запрос модифицируется программно. Значит нужно как минимум его проверить на корректную работоспособность.
Сугубо мое личное мнение. Основанное на личном опыте.
А вообще давно по себе заметила, что все интересные вещи делаются сразу. Т.е. продумал, сел и написал. Если пытаешься что-то сделать и оно не получается или получается слишком запутанно, то значит плохо продумал, не хватает теоретического понимания темы. Тогда нужно не лепить заплатки, а просто отложить и сделать потом.
(32) mixsture, Если мы формируем запрос текстом и лишь програмно добавляем условие, то он отлично открывается конструктором. Написать "ТекстЗапроса = ТекстЗапроса+<Условие>" мы можем лишь в случае, если условие нужно в конце текста. Если запрос пакетный либо есть итоги, то условия в конец дописать нельзя. Только разрывать запрос.
По строковым функциям согласна, мне их тоже не хватает.
По чтению вроде ж сделали. ИМХО, версионное чтение в 8.3 лучше, чем просто грязное чтение. Данные целостные, блокировок нет и на производительности не сказывается.
И таким образом поиск ошибок абсолютно не меняется - встаем отладкой перед Запрос.Выполнить и смотрим текст запроса.
Идеальным было бы научить сам объект Запрос корректно оптимизировать условия "флагОтбора или отбор". Тогда можно не рвать запрос и все хорошо открывается в конструкторе, а также все составляющие запроса сразу видны в 1 месте.
Меня, например, в рвущемся запросе сильно раздражает - что конструктор запроса из конфигуратора не открыть - приходится включать отладку, выдергивать полный текст запроса непосредственно перед Запрос.Выполнить() - и на нем уже открывать конструктор. Я так понимаю, со схемой запроса ситуация ничуть не улучшилась, верно?
Опять же - рвем запрос, как правило, для условного отбора, чтобы работал побыстрее. Есть вариант менее производительный (флаг отбора и отбор объединены по ИЛИ. или как вариант - оператором ВЫБОР):
|ВЫБОР
| КОГДА &ИспользованиеОтбораСклад
| ТОГДА СправочникСклады.Ссылка = &Склад
| ИНАЧЕ ИСТИНА
| КОНЕЦ
В этой ситуации здорово было бы, чтобы оптимизатор понял, что флаг - это константа в запросе, его можно вычислить 1 раз до выполнения запроса и не выполнять проверку условия СправочникСклады.Ссылка = &Склад, если из-за флага туда исполнение не зайдет.
Но он так не умеет и поэтому работает медленнее. И поэтому приходится делать некрасиво, зато быстро
Если флагОтбора Тогда
ТекстЗапроса = ТекстЗапроса + " СправочникСклады.Ссылка = &Склад"
КонецЕсли;
Со схемой запроса получаем абсолютно тоже самое.
Странное направление развития у 1с. Казалось бы, могли бы поправить вычисление "констант" и все за это сказали бы спасибо. Могли бы добавить нормальное количество строковых функций в запросах (почему-то в любом SQL их предостаточно, а 1с решила пойти по пути минимализма). Могли бы добавить возможность вмешиваться в генерируемый на чистом SQL запрос - например, программист смог бы делать грязное чтение - иногда точность последних данных не критична, зато быстрее. Но 1с вводит сомнительные улучшения.
чтобы не городить в тексте запроса конструкций типа:
|ВЫБОР
| КОГДА &ИспользованиеОтбораСклад
| ТОГДА СправочникСклады.Ссылка = &Склад
| ИНАЧЕ ИСТИНА
| КОНЕЦ
Я добавляю в текст запроса равенство типа
ТекстЗапроса = "...ГДЕ 1 = 1 И 2 = 2...";
Далее, анализ выбранных значений и при необходимости модификация текста запроса:
Если ИспользованиеОтбораСклад Тогда
ЗапросТекст = СтрЗаменить(ЗапросТекст, "1 = 1", "СправочникСклады.Ссылка = &Склад");
Запрос.УстановитьПараметр("Склад", ВыбСклад);
КонецЕсли;
Я уже наелся, когда в отчете на схеме компановке на кой-то хрен подменяют перед формированием запрос, получая его из общего модуля при этом несколько раз применив к тексту "СтрЗаменить(ТекстЗапроса,...,...)" и вызвав 10 вложенных функций.
Итак в этой каше отлаживаться и добавлять свой функционал - огромные трудозатраты.
А теперь вообще жесть будет.
Возьмут они текст запроса и будут его потом кодом модифицировать. А как мне его конструктором посмотреть, чтобы понять, что они там получают?
А как мне свои поля протаскивать через 20 временных таблиц после такого изврата над запросом?
Для масштабируемости решений главное - читабельность, а это новшество уничтожает читабельность.
Схема запроса более стандартный механизм. Думаю, будут использовать в типовых решениях.
А объектная модель может быть использована для грамотного парсинга запросов в самых разных консолях - в т.ч. и под управляемые формы, т.к. с ней - не требуется извращаться с ВК. Можно написать свой конструктор запросов... Да много чего ещё можно сделать.
(48) По поводу громоздкости - согласен, не всегда удобно. Но и объёмы данных приходится представлять тоже немалые...
Бирюзовым - примитивные типы, специфичные для схемы запроса;
Правильнее было бы:
Зеленым - примитивные типы (строка, число, булево);
Бирюзовым - системные перечисления, использующиеся в схеме запроса.
>>изменение имеющегося запроса
Я подумал, что можно писать обычный запрос, а потом обратиться к его объектам и изменить что нужно, не разрывая, но в публикации не нашёл такой реализации. Это невозможно? Тогда подпишусь под комментаторами, считающими это нагромождением, тем более без штатного конструктора.
UPD: нашёл описание нужной реализации на сайте 1С, вот так делается:
Вот почитайте, сколько всего доработано по объектной модели запроса в 8.3.7, и подумайте - а стоило горбатиться раньше-то?
Терпение, терпение). Юзайте уже устаканившееся, меньше переделывать придётся)))
P.S. Считайте это моим общим ответом автору публикации, большой любительнице интенсивно копаться в каждой полусырой новинке)
ИсточникСхемыЗапроса.Источник.Параметры[0].Выражение = Новый ВыражениеСхемыЗапроса("&КонецПериода");
ИсточникСхемыЗапроса.Источник.Параметры[1].Выражение = Новый ВыражениеСхемыЗапроса("Организация = &Организация");
Товар В
(ВЫБРАТЬ РАЗЛИЧНЫЕ
ОстаткиИОбороты.Товар
ИЗ
ОстаткиИОбороты)
И Организация = &Организациядобавить еще например
Договор В (&Договоры)Красиво получается?
1. есть ли возможность добавлять комментарии в создаваемый запрос через СхемуЗапроса (т.е. во время отладки при определении выражения переменной, присвоенной методом ПолучитьТекстЗапроса можно будует просмотреть запрос целиком, а что на счет комментариев в этом тексте)?
В запрос в качестве таблицы-источника можно использовать таблицу значений, предварительно ее "типизировать" и передать параметром запроса, как такое провернуть используя схему запроса?
Пример:
Запрос.УстановитьПараметр("ТаблицаИсточник ", ТаблицаИсточник );
...
"ВЫБРАТЬ
| ТаблицаИсточник .Поле1,
| ТаблицаИсточник .Поле2
|ПОМЕСТИТЬ ВТ_ТаблицаИсточник
|ИЗ
| &ТаблицаИсточник КАК ТаблицаИсточник
|;
...
решено
ИсточникПакета0 = ОператорыПакет0.Источники.Добавить(Тип("ОписаниеВременнойТаблицыСхемыЗапроса"),"&ТаблицаИсточник ");
еще Важный момент :
ОператорыТекПакет.ВыбираемыеПоля.Добавить("ТаблицаИсточник ."+поле);
Добавляем в качестве источника вложенный запрос.
Здесь "Список.ТекстЗапроса" - это текст запроса динамического списка.
СхемаЗапроса = Новый СхемаЗапроса;
СхемаЗапроса.УстановитьТекстЗапроса(Список.ТекстЗапроса);
ЗапросВыбора = СхемаЗапроса.ПакетЗапросов[0];
ОператорВыбрать = ЗапросВыбора.Операторы[0];
ОсновнойИсточник = ОператорВыбрать.Источники[0];
ВложенныйЗапросПеремещения =
"ВЫБРАТЬ
| ПеремещениеТоваров.ЗаказНаПеремещение.ДокументОснование КАК ЗаказНаПеремещениеДокументОснование,
| МАКСИМУМ(ИСТИНА) КАК ЕстьНезакрытыеПеремещения
|ИЗ
| Документ.ПеремещениеТоваров КАК ПеремещениеТоваров
|ГДЕ
| ПеремещениеТоваров.Статус <> ЗНАЧЕНИЕ(Перечисление.СтатусыПеремещенийТоваров.Принято)
| И ПеремещениеТоваров.Проведен = ИСТИНА
|
|СГРУППИРОВАТЬ ПО
| ПеремещениеТоваров.ЗаказНаПеремещение.ДокументОснование";
НовыйИсточник = ОператорВыбрать.Источники.Добавить(Тип("ВложенныйЗапросСхемыЗапроса"), "ВложенныйЗапросПеремещения");
НовыйИсточник.Источник.Запрос.УстановитьТекстЗапроса(ВложенныйЗапросПеремещения);
НовыйИсточник.Соединения.Добавить(ОсновнойИсточник, "ДокументЗаказКлиента.Ссылка = ВложенныйЗапросПеремещения.ЗаказНаПеремещениеДокументОснование");
НовыйИсточник.Соединения[0].ТипСоединения = ТипСоединенияСхемыЗапроса.ПравоеВнешнее;
Список.ТекстЗапроса = СхемаЗапроса.ПолучитьТекстЗапроса();
ПоказатьСхемаЗапроса.ПакетЗапросов[0].Операторы[0].ВыраженияОтбораКомпоновкиДанныхДоступен, начиная с версии 8.3.14.
Кстати, столкнулся с проблемой. При установке текста запроса автоматически присваиваются псевдонимы полей компоновки данных.
Пришлось их очищать.
В запросе есть Полное соединение. Я хочу добавить еще одно.
Но при добавлении нельзя указать тип соединения, оно по умолчанию левое. Поэтому при вызове Соединения.Добавить() падает исключение "Противоречивая связь".
Необходимо было в текст соединения двух таблиц запроса:
|ИЗ
| ВТОтборовСотрудников КАК ТаблицаОтборов
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам КАК ЛицевыеСчетаСотрудников
| ПО ТаблицаОтборов.ФизическоеЛицо = ЛицевыеСчетаСотрудников.ФизическоеЛицо
| И (ВЫБОР
| КОГДА ТаблицаОтборов.Период = ДАТАВРЕМЯ(1, 1, 1)
| ТОГДА &МаксимальнаяДата
| ИНАЧЕ ТаблицаОтборов.Период
| КОНЕЦ >= ЛицевыеСчетаСотрудников.ДатаОткрытияЛицевогоСчета)
Показатьдобавить условие
| И ТаблицаОтборов.Сотрудник.ГоловнаяОрганизация = ЛицевыеСчетаСотрудников..Организация.ГоловнаяОрганизация
Планировал сделать так:
Соединения = СхемаЗапроса.ПакетЗапросов[0].Операторы[0].Источники[0].Соединения;
ДобавляемоеУсловие = Новый ВыражениеСхемыЗапроса("ТаблицаОтборов.Сотрудник.ГоловнаяОрганизация = ЛицевыеСчетаСотрудников.Организация.ГоловнаяОрганизация");
Соединения.Добавить("ТаблицаОтборов", ДобавляемоеУсловие);
ПозицияУсловия = Соединения.Количество()-1;
Соединения[ПозицияУсловия].ТипСоединения = ТипСоединенияСхемыЗапроса.Внутреннее;
однако до указания типа соединения не смог добраться. При добавлении соединения вываливаюсь по исключению.
Обошел это ограничение, добавив необходимое мне условие в одно из существующих соединений, модифицировав тест условия:
//Обходим соединения и позиционируемся на соединении по искомому условию
Для Каждого Соединение Из СхемаЗапроса.ПакетЗапросов[0].Операторы[0].Источники[0].Соединения Цикл
Если Соединение.Условие = ИскомоеУсловие Тогда
//Добавляем в условие по физлицу условие по организации
Соединение.Условие = Новый ВыражениеСхемыЗапроса("ТаблицаОтборов.Сотрудник.ФизическоеЛицо = ЛицевыеСчетаСотрудников.ФизическоеЛицо И ТаблицаОтборов.Сотрудник.ГоловнаяОрганизация = ЛицевыеСчетаСотрудников.Организация.ГоловнаяОрганизация");
КонецЕсли;
КонецЦикла;
ПоказатьВ итоге доработанный текст запроса стал выглядеть так:
|ИЗ
| ВТОтборовСотрудников КАК ТаблицаОтборов
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам КАК ЛицевыеСчетаСотрудников
| ПО (ТаблицаОтборов.ФизическоеЛицо = ЛицевыеСчетаСотрудников.ФизическоеЛицо
| И ТаблицаОтборов.Сотрудник.ГоловнаяОрганизация = ЛицевыеСчетаСотрудников..Организация.ГоловнаяОрганизация)
| И (ВЫБОР
| КОГДА ТаблицаОтборов.Период = ДАТАВРЕМЯ(1, 1, 1)
| ТОГДА &МаксимальнаяДата
| ИНАЧЕ ТаблицаОтборов.Период
| КОНЕЦ >= ЛицевыеСчетаСотрудников.ДатаОткрытияЛицевогоСчета)
ПоказатьВ отдельных простых ситуациях это выход.
Но хотелось бы понимать как правильно добавлять условия в существующие "не левые" соединения.
Была следующая идея:
1. Пробежаться по существующим условиям в которые необходимо добавить свое.
2. Сохранить их и тип связи.
3. Очистить существующие соединения.
4. По списку (таблице) сохраненных условий соедиения создать новые с типом соединения "Левое" (т.е. "по умолчанию").
5. Добавить свое условие (так же с типом соединения "Левое").
6. Изменить тип соединения на необходимое ("Внутреннее", "ПолноеВнешнее", "ПравоеВнешнее")
Предполагаю, что алгоритм правильный, но пока реализовать руки не дошли (работает выше описанный вариант).
Подводный камень вижу при попытке изменить тип соединения для одного из условий, когда условий больше одного. Нужно проверить.
Если дойдут руки проверить - отпишусь.
так там используются комментарии, наподобие, "//ОператорПОМЕСТИТЬ"
которые, дальше, меняются на куски кода
при преобразовании в СЗ и обратно они теряются и усё приплыли ..... кто нибудь решал такую задачу ?
ОператорВыбратьОбъединение = ОператорВыбораЗакупок.ДобавитьОператор(ЗапросВыбораИзИБ, Новый Структура("ТипОбъединения", ТипОбъединенияСхемыЗапроса.Объединить)); Решаю как раз задачку, когда имеется три текста запроса, в первом выборка по клиентам, в третьем по поставщикам, а второй текстик это
ТекстОбъединения =
"ОБЪЕДИНИТЬ ВСЕ
| ";
И вот если конкатенацией всё просто, либо текст1, либо текст2 либо Текст1+ТекстОбъединения +Текст2, то со схемой запроса пошел по сложному пути, сначала собрал "максимальный" текст запроса а потом пробую из него удалять всё ненужное, в зависимости от настроек. Если выгорит отпишусь, готовых примеров не нашел
В моём случае в зависимости от того, какую таблицу надо было оставить, делал либо
СхемаЗапросаОбщая.ПакетЗапросов[5].Операторы.Удалить(1)
Либо
СхемаЗапросаОбщая.ПакетЗапросов[5].Операторы.Удалить(0)
Но во втором случае слетали псевдонимы полей, так что ещё добавил код присваивания,
СхемаЗапросаОбщая.ПакетЗапросов[5].Колонки[1].Псевдоним = "ДокументДвижения"; И т.д.
Еще иногда советуют читать ЖКК (в основном на мисте и др. форумах такое можно встретить) - Желто-Красная книжка, речь о бумажной документации, которая когда-то шла в составе тиражных коробок:)
Нужно было добавить формирование временной таблицы потом связать с таблицей списка, обозначить поля запроса, а потом на форме списка добавить соответствующие элементы (колонки списка).
Такой универсальный однотипный механизм - чтобы не морочаться с текстами запросов в формах списков, вызвал универсальную "библиотечную процедуру" и получил результат.
Для такой задачи - самое оно!!!
Возможно, вам будет интересно:
в тексте запроса 1С использует в секции выбора полей {ГДЕ} и соответственно их перечисляет. Контруктор же после прогона через себя успешно секцию {ГДЕ} по списком полей переносит после секции ИЗ и естественно запрос уже не работает правильно. те конструктор самовольно переносит поля компоновщика в условия компоновщика. Как решить данную проблему? Не хотелось бы ручками писать так как это может привести к неработоспособности конфы после обновления. Может кто-нибудь знает решение?
т.е. до схемы запроса запрос выглядел так:
ВЫБРАТЬ
....
{ГДЕ
(ДокументыПредприятия.ДатаСортировки >= &ОтборПериодНачало)}
ИЗ
РегистрСведений.ДанныеДокументовПредприятия КАК ДокументыПредприятия
После применения схемы запрос выглядит так
ВЫБРАТЬ
....
ИЗ
РегистрСведений.ДанныеДокументовПредприятия КАК ДокументыПредприятия
{ГДЕ
(ДокументыПредприятия.ДатаСортировки >= &ОтборПериодНачало)}
ЗапросВыбораИзИБ.Колонки[2].Поля.Установить(1,ВыражениеЗакупки); Не работает!
Получилось так
НовыйОператор.ВыбираемыеПоля.Добавить("Ссылка", 0); Где цифра "0" - это номер колонки с которой будет сопоставлено из первого запроса объединения.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 307045
Создание 12.10.14 23:43
Обновление 12.10.14 23:43
Просмотры 160334
Загрузки 0
Рейтинг
383
Комментарии 98
Код открыт Не указано
Рубрики Запросы
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
