Чудеса с СКД или «Поле не входит в группу».

Написал отчет. Отладил в консоле отчетов. Все работает.
Переношу в СКД. Ошибка: https://s.mail.ru/FMPS/x6nRPFZXW
Даже не знаю в какую сторону копать.
Заранее спасибо.
Пытался делать отчет в базе копии. Тоже самое.

Ошибка на строки:
ВЫБРАТЬ
ПЕРВЫЕ 10000
КОЛИЧЕСТВО(*) КАК Номер,
ВТ4.Соглашение,
ВТ4.Путевой,
ВТ4.КодировкаДоставки
ПОМЕСТИТЬ ВТ55
ИЗ
ВТ4 КАК ВТ4,
ВТ4 КАК ВТ41
ГДЕ
ВТ4.КодировкаДоставки >= ВТ41.КодировкаДоставки

СГРУППИРОВАТЬ ПО
ВТ4.Соглашение,
ВТ4.Путевой,
ВТ4.КодировкаДоставки
УПОРЯДОЧИТЬ ПО
ВТ4.КодировкаДоставки

ВЫБРАТЬ
АВЭКС_ЗаданияТрейдПойнт.Идентификатор,
АВЭКС_ЗаданияТрейдПойнт.Соглашение,
АВЭКС_АвтомобилиТрейдПойнт.ТранспортноеСредство,
АВЭКС_АвтомобилиТрейдПойнт.НомерТелефона,
АВЭКС_ЗаданияТрейдПойнт.Регистратор,
АВЭКС_ЗаданияТрейдПойнт.Период,
АВЭКС_ЗаданияТрейдПойнт.Статус
ПОМЕСТИТЬ ВТ1
ИЗ
РегистрНакопления.АВЭКС_ЗаданияТрейдПойнт КАК АВЭКС_ЗаданияТрейдПойнт
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.АВЭКС_АвтомобилиТрейдПойнт КАК АВЭКС_АвтомобилиТрейдПойнт
ПО АВЭКС_ЗаданияТрейдПойнт.Идентификатор = АВЭКС_АвтомобилиТрейдПойнт.ИдентификаторТрейдПойнт
ГДЕ
АВЭКС_АвтомобилиТрейдПойнт.Работает
И АВЭКС_АвтомобилиТрейдПойнт.ТранспортноеСредство = &ТранспортноеСредство
И АВЭКС_ЗаданияТрейдПойнт.Период МЕЖДУ &ДатаНачала И КОНЕЦПЕРИОДА(&ДатаОкончания, ДЕНЬ)
И АВЭКС_ЗаданияТрейдПойнт.Активность
И АВЭКС_ЗаданияТрейдПойнт.ТипЗадания = ЗНАЧЕНИЕ(Перечисление.Авэкс_ТипыЗаданийТрейдПойнт.d)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
МАКСИМУМ(ВТ1.Регистратор.ДатаВремяРейсаФактС) КАК ВремяСтарта,
МАКСИМУМ(ВТ1.Регистратор.ДатаВремяРейсаПланПо) КАК ВремяПрибытия,
ВТ1.Регистратор
ПОМЕСТИТЬ ДатаСтартаПрибытия
ИЗ
ВТ1 КАК ВТ1
ГДЕ
ВТ1.Статус = 0

СГРУППИРОВАТЬ ПО
ВТ1.Регистратор
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТ2.Идентификатор,
ВТ2.Соглашение,
ВТ2.ТранспортноеСредство,
К.КОЛИЧЕСТВО
ПОМЕСТИТЬ ВТ22
ИЗ
ВТ2 КАК ВТ2
ВНУТРЕННЕЕ СОЕДИНЕНИЕ К КАК К
ПО (ИСТИНА)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТ22.Идентификатор,
ВТ22.Соглашение,
ВТ22.КОЛИЧЕСТВО,
ВТ22.ТранспортноеСредство,
ВТ1.Регистратор.Дата,
ВТ1.Регистратор,
ВТ1ПУТЕВОЙ.Регистратор КАК Путевой,
ВЫБОР
КОГДА ВТ1.Регистратор ССЫЛКА Документ.АВЭКС_ВыполнениеЗаданийТрейдПойнт
ТОГДА ВТ1.Регистратор.ДокОснование.ДатаВремяРейсаФактС
ИНАЧЕ NULL
КОНЕЦ КАК ВремяСтарта,
ВЫБОР
КОГДА ВТ1.Регистратор ССЫЛКА Документ.АВЭКС_ВыполнениеЗаданийТрейдПойнт
ТОГДА ВТ1.Регистратор.ДокОснование.ДатаВремяРейсаПланПо
ИНАЧЕ NULL
КОНЕЦ КАК ВремяПрибытия,
Партнеры.КодировкаДоставки КАК КодировкаДоставки
ПОМЕСТИТЬ ВТ3
ИЗ
ВТ22 КАК ВТ22
ЛЕВОЕ СОЕДИНЕНИЕ ВТ1 КАК ВТ1
ПО (ВТ1.Идентификатор = ВТ22.Идентификатор)
И (ВТ1.Соглашение = ВТ22.Соглашение)
И (ВТ1.ТранспортноеСредство = ВТ22.ТранспортноеСредство)
И (ВТ1.Статус = 1)
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры КАК Партнеры
ПО ВТ22.Соглашение.Партнер = Партнеры.Ссылка
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ1 КАК ВТ1ПУТЕВОЙ
ПО (ВТ1ПУТЕВОЙ.Идентификатор = ВТ22.Идентификатор)
И (ВТ1ПУТЕВОЙ.Соглашение = ВТ22.Соглашение)
И (ВТ1ПУТЕВОЙ.ТранспортноеСредство = ВТ22.ТранспортноеСредство)
И (ВТ1ПУТЕВОЙ.Статус = 0)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ПЕРВЫЕ 10000
КОЛИЧЕСТВО(*) КАК Номер,
ВТ4.Соглашение,
ВТ4.Путевой,
ВТ4.КодировкаДоставки
ПОМЕСТИТЬ ВТ55
ИЗ
ВТ4 КАК ВТ4,
ВТ4 КАК ВТ41
ГДЕ
ВТ4.КодировкаДоставки >= ВТ41.КодировкаДоставки

СГРУППИРОВАТЬ ПО
ВТ4.Соглашение,
ВТ4.Путевой,
ВТ4.КодировкаДоставки
УПОРЯДОЧИТЬ ПО
ВТ4.КодировкаДоставки
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТ55.Номер,
ВТ55.Соглашение,
ВТ55.Путевой,
ДатаСтартаПрибытия.ВремяСтарта,
ДатаСтартаПрибытия.ВремяПрибытия
ПОМЕСТИТЬ ВТ5
ИЗ
ВТ55 КАК ВТ55
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ДатаСтартаПрибытия КАК ДатаСтартаПрибытия
ПО ВТ55.Путевой = ДатаСтартаПрибытия.Регистратор
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТ3.Идентификатор,
ВТ3.Соглашение,
ВТ3.КОЛИЧЕСТВО,
ВТ3.ТранспортноеСредство,
ВТ3.Регистратор,
ВТ5.Путевой,
ВТ3.КодировкаДоставки,
ВТ5.Номер,
ВТ5.ВремяСтарта,
ВТ5.ВремяПрибытия,
ВЫБОР
КОГДА ВТ3.КОЛИЧЕСТВО <> 0
ТОГДА ДОБАВИТЬКДАТЕ(ВТ5.ВремяСтарта, СЕКУНДА, ВЫРАЗИТЬ(РАЗНОСТЬДАТ(ВТ5.ВремяСтарта, ВТ5.ВремяПрибытия, СЕКУНДА) / ВТ3.КОЛИЧЕСТВО * ВТ5.Номер КАК ЧИСЛО(15, 0)))
ИНАЧЕ 0
КОНЕЦ КАК Шаг
ПОМЕСТИТЬ ВТ6
ИЗ
ВТ5 КАК ВТ5
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ3 КАК ВТ3
ПО ВТ5.Соглашение = ВТ3.Соглашение
И ВТ5.Путевой = ВТ3.Путевой
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
// ВТ6.Идентификатор,
ВТ6.Соглашение,
// ВТ6.КОЛИЧЕСТВО,
ВТ6.ТранспортноеСредство,
ВТ6.Регистратор,
ВТ6.Путевой,
ВТ6.КодировкаДоставки,
ВТ6.Номер,
ВТ6.ВремяСтарта,
ВТ6.ВремяПрибытия,
ВТ6.Шаг,
ВЫБОР
КОГДА ВТ6.Шаг Cyberhawk

Источник

Проверить в запросе на вхождение параметра в группу

Ошибка:
Неверные параметры «В ИЕРАРХИИ»
И &ПарамКлиент В иерархии ( >лк_ПравилаПечатиМаркЛиста.Контрагент)

Обычный иерархический запрос с этим тоже справится.

Обычный иерархический запрос с этим тоже справится.

(23)В таком случае, запрос можно превратить в:

а если речь идет о проверке, группа это или элемент, то следует проверять на

Умная книга рекомендует:

Получение всех родителей элемента
В языке запросов не предусмотрено специальных средств для получения всех родителей элемента. Для выполнения задачи можно воспользоваться иерархическими итогами, однако получение иерархических итогов оптимизировано для построения итогов большого количества записей, и не вполне эффективно для получения родителей одного элемента. Для более эффективного получения всех родительских записей элемента, рекомендуется перебирать в цикле его родителей небольшими порциями. Пример:
Пример:
ТекущийЭлементНоменклатуры = ЭлементНоменклатура;

Запрос = Новый Запрос(«ВЫБРАТЬ
| Номенклатура.Родитель,
| Номенклатура.Родитель.Родитель,
| Номенклатура.Родитель.Родитель.Родитель,
| Номенклатура.Родитель.Родитель.Родитель.Родитель,
| Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
|
|ГДЕ
| Номенклатура.Ссылка = &ТекущийЭлементНоменклатуры»;

Если ТекущийЭлементНоменклатуры = Справочники.Номенклатура.ПустаяСсылка() Тогда
Прервать;
КонецЕсли;
КонецЦикла;
В данном примере в окно служебных сообщений выводятся все родители для ссылки, записанной в переменную ЭлементНоменклатура. В цикле выбирается по 5 родителей ссылки.
Если число уровней в справочнике ограничено и невелико, то возможно получение всех родителей одним запросом без цикла.

Источник

Запрос. Поле не входит в группу «Альянс_Заявка.Дата»

Добрый вечер. Помогите, пожалуйста, составить запрос для динамического списка.
Есть документ А (типа главный), в нем есть ссылка на документ Б. В документе Б есть табличная часть с циферками. Мне нужно, чтобы запрос выдавал поля документа А (номер, дата, комментарий и т.п.) И сумму по столбцу из табличной части документа Б. Вот что я наваял:

ВЫБРАТЬ
Альянс_Заявка.Дата,
Альянс_Заявка.Наименование,
Альянс_Заявка.Заказчик,
Альянс_Заявка.ТипДокумента,
Альянс_Заявка.НомерДокумента,
Альянс_Заявка.Себестоимость,
Альянс_Заявка.Стоимость,
Альянс_Заявка.Прибыль,
Альянс_Заявка.ОТК,
Альянс_Заявка.ДополнительнаяИнформация,
Альянс_Заявка.СчетНаОплатуКлиента.СуммаДокумента,
Альянс_Заявка.СчетНаОплатуКлиента.Номер,
Альянс_Заявка.СчетНаОплатуКлиента.Дата,
Альянс_Заявка.Орган,
Альянс_Заявка.НомерСчетаОтОргана,
Альянс_Заявка.ОплаченоОргану,
ЕСТЬNULL(СУММА(CRM_СчетНаОплатуПокупателяТаблОплата.Сумма), 0) КАК СуммаПП
ИЗ
Документ.Альянс_Заявка КАК Альянс_Заявка
ЛЕВОЕ СОЕДИНЕНИЕ Документ.CRM_СчетНаОплатуПокупателю.Оплата КАК CRM_СчетНаОплатуПокупателяТаблОплата
ПО CRM_СчетНаОплатуПокупателяТаблОплата.Ссылка = Альянс_Заявка.Ссылка
<ГДЕ
(Альянс_Заявка.Заказчик = &Партнер)>

Вот что мне на это ответил конфигуратор:
Ошибка получения информации набора данных
по причине:
Ошибка в запросе набора данных
по причине:
<(2, 2)>: Поле не входит в группу «Альянс_Заявка.Дата»
>Альянс_Заявка.Дата,

Источник

Типичные причины неоптимальной работы запросов и методы оптимизации

Краткое содержание:

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

Значительная часть проблем, приводящих к неоптимальной работе запросов, может быть обнаружена путем анализа кода конфигурации и структуры метаданных. Имеется перечень типичных ошибок в коде и структуре данных, последствия которых достаточно хорошо изучены и легко предсказуемы. Анализ кода с использованием этого перечня позволяет решить большую часть проблем с производительностью запросов, не углубляясь в детальную техническую информацию (текст запроса на языке SQL, план запроса и т.д.).

Основные причины неоптимальной работы запросов, диагностируемые на уровне кода конфигурации и структуры метаданных:

В настоящей статье рассматриваются перечисленные причины неоптимальной работы запросов и даются рекомендации по их оптимизации.

Cоединения с подзапросами

Рекомендации

Если запрос содержит соединения с подзапросами, то это может привести к следующим негативным последствиям:

Пример потенциально опасного запроса, использующего соединение с подзапросом:

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

Для оптимизации запроса следует разбить его на несколько отдельных запросов (по числу подзапросов, используемых в соединениях). Эти запросы рекомендуется поместить в один пакетный запрос.

Внимание! Не забудьте проиндексировать созданную временную таблицу. В качестве индексных полей следует указать все поля, которые используются в условии соединения.

Для вышеприведенного примера получится следующий пакетный запрос:

Пояснения

Оптимизатор сервера СУБД (независимо от того, какую СУБД вы используете) не всегда может правильно оптимизировать подобный запрос. В данном случае, проблемой для оптимизатора является выбор правильного способа соединения. Существуют несколько алгоритмов соединения двух выборок. Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке. В том случае, если вы соединяете две физические таблицы, СУБД может легко определить объем обоих выборок на основании имеющейся статистики. Если же одна из соединямых выборок представляет собой подзапрос, то понять, какое количество записей она вернет, становится очень сложно. В этом случае СУБД может ошибиться с выбором плана, что приведет к катастрофическому падению производительности запроса.

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

Cоединения с виртуальными таблицами

Рекомендации

Если в запросе используется соединение с виртуальной таблицей языка запросов 1С:Предприятия (например, «РегистрНакопления.Товары.Остатки()») и запрос работает с неудовлетворительной производительностью, то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.

То есть, следует использовать ту же рекомендацию, что и в случае соединения с подзапросом.

Пояснения

Виртуальные таблицы, используемые в языке запросов 1С:Предприятия, могут разворачиваться в подзапросы при трансляции в язык SQL. Это связано с тем, что виртуальная таблица часто (но не всегда) получает данные из нескольких физических таблиц СУБД. Если вы используете соединение с виртуальной таблицей, то на уровне SQL оно может быть в некоторых случаях реализовано, как соединение с подзапросом. В этом случае оптимизатор СУБД может точно так же выбрать неоптимальный план, как при работе с подзапросом, использованным в языке 1С:Предприятия в явном виде.

Несоответствие индексов и условий запроса

Рекомендации

Убедитесь в том, что для всех условий, использованных в запросе, имеются подходящие индексы.

Условия используются в следующих секциях запроса:

Для каждого условия должен существовать подходящий индекс. Подходящим является индекс, удовлетворяющий следующим требованиям:

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

Основные идексы, создаваемые 1С:Предприятием:

Детальная информация по индексам, автоматически создаваемым 1С:Предприятием содержится в статье «Индексы таблиц базы данных 1С:Предприятия 8.1».

В тех случаях, когда автоматически созданных индексов недостаточно, можно дополнительно проиндексировать реквизиты объекта метаданных. Информация о том, какие индексы при этом будут созданы, содержится в этой же статье. Следует иметь в виду, что создание индекса ускоряет процесс поиска информации, но может несколько замедлить процесс ее изменения (добавления, редактирования и удаления). Поэтому индексы следует создавать осознанно и только в том случае, если точно известен запрос, для которого такой индекс необходим. Не следует создавать индексы «на всякий случай» или заведомо избыточные индексы. Например никогда не следует дополнительно индексировать первое измерение регистра, поскольку для поиска по значению первого измерения подходит основной индекс таблицы итогов, который автоматически создаст платформа.

Пояснения

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

Примеры

В конфигурации описан регистр накопления ТоварыНаСкладах:

Платформа 1С:Предприятие автоматически создаст для таблицы остатков данного регистра индекс по периоду и всем измерениям в том порядке, в котором они перечислены в конфигураторе.

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

Запрос 1

В данном случае нарушено требование 2. В условии отсутствует отбор по первому полю индекса (Склад). Такой запрос не сможет выполниться оптимально. Для его выполнения серверу СУБД придется перебирать (сканировать) все записи таблицы. Время выполнения этой операции напрямую зависит от количества записей в таблице остатков регистра и может быть очень большим (и будет увеличиваться с ростом количества данных).

Запрос 2

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

Запрос 3

В этом случае требования соответствия индекса и запроса не нарушены. Данный запрос будет выполнен СУБД оптимальным способом. Обратите внимание на то, что порядок следования условий в запросе не обязан совпадать с порядком следования полей в индексе. Это не является проблемой и будет нормально обработано СУБД.

Использование логического ИЛИ в условиях

Рекомендации

Использование логического ИЛИ в секции ГДЕ запроса

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.

следует заменить на запрос

Включение пользователей в несколько ролей, каждая из которых имеет RLS

Использование ИЛИ в условиях соединения

Не рекомендуется использовать логическое ИЛИ в условиях соединения, то есть в секции ПО запроса. Это так же может привести к выбору неоптимального плана и медленной работе запроса. Простого универсального способа переписать такой запрос без использования ИЛИ не существует. Следует проанализировать решаемую задачу и попытаться найти другой алгоритм ее решения.

Использование подзапросов в условии соединения

Рекомендации

Не следует использовать подзапросы в условии соединения. Это может привести к значительному замедлению запроса и (в отдельных случаях) к его полной неработоспособности на некоторых СУБД. Пример запроса с использованием подзапроса в условии соединения:

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

Получение данных через точку от полей составного типа

Рекомендации

Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности и даже к неработоспособности запроса в отдельных случаях.

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

Пример

В данном запросе используется обращение к реквизитам регистратора. Регистратор является полем составного типа, которое может принимать значения ссылки на один из 56 видов документов.

SQL-текст этого запроса будет включать 56 левых соединений с таблицами документов. Это может привести к серьезным проблемам производительности при выполнении запроса. Однако, для решения данной конкретной задачи нет необходимости соединяться со всеми 56 видами документов. Условия запроса таковы, что при его выполнении будут выбраны только движения документов «РеализацияТоваровУслуг» и «ЗаказыПокупателя». В этом случае мы можем значительно ускорить работу запроса, ограничив количество соединений при помощи функции ВЫРАЗИТЬ().

Фильтрация виртуальных таблиц без использования параметров

При использовании виртуальных таблиц в запросах, следует передавать в параметры таблиц все условия, относящиеся к данной виртуальной таблице. Не рекомендуется фильтровать виртуальные таблицы при помощи условий в секции ГДЕ и т.п. Такой запрос будет возвращать правильный (с точки зрения функциональности) результат, но СУБД будет намного сложнее выбрать оптимальный план для его выполнения. В некоторых случаях это может привести к ошибкам оптимизатора СУБД и значительному замедлению работы запроса.

Например, следующий запрос использует секцию ГДЕ запроса для выборки из виртуальной таблицы.

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

Источник