Ошибка «Неверные параметры» при использовании временной таблицы в запросе

Здравствуйте! Задача: написать запрос, формирующий статистику продаж по номенклатуре, а именно максимальные дневные продажи за период. Хочу реализовать это именно через временную таблицу по некоторым причинам. Использую универсальный отчет, на данный момент написал 2 запроса:

Запрос №1: «СформироватьВТ()». Выгружает ТаблицуЗначений по продажам. Он довольно длинный и заурядный, но если нужно тоже выложу.

Данный запрос сократил, для удобства чтения, т.к. на ошибку это не влияет.

ВЫБРАТЬ РАЗРЕШЕННЫЕ
ВТПродажи.Количество,
ВТПродажи.Номенклатура,
ВТПродажи.Склад,
ВТПродажи.День
ПОМЕСТИТЬ ВыборкаПродажи
ИЗ
&ВТПродажи КАК ВТПродажи
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
МАКСИМУМ(ВыборкаПродажи.Количество) КАК Количество,
ВложенныйНоменклатура.Склад,
ВложенныйНоменклатура.Номенклатура
ИЗ
(ВЫБРАТЬ
Склады.Ссылка КАК Склад,
Номенклатура.Ссылка КАК Номенклатура
ИЗ
Справочник.Склады КАК Склады,
Справочник.Номенклатура КАК Номенклатура
ГДЕ
Номенклатура.ЭтоГруппа = ЛОЖЬ
И Склады.ЭтоГруппа = ЛОЖЬ) КАК ВложенныйНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ ВыборкаПродажи КАК ВыборкаПродажи
ПО ВложенныйНоменклатура.Склад = ВыборкаПродажи.Склад
И ВложенныйНоменклатура.Номенклатура = ВыборкаПродажи.Номенклатура

СГРУППИРОВАТЬ ПО
ВложенныйНоменклатура.Склад,
ВложенныйНоменклатура.Номенклатура

Полный текст ошибки:
<ВнешнийОтчет.ЗапасыИТочкиЗаказа.МодульОбъекта(157)>: Ошибка при установке значения атрибута контекста (Текст)
УниверсальныйОтчет.ПостроительОтчета.Текст = ТекстЗапроса;
по причине:
<(8, 2)>: Неверные параметры «ВТПродажи»
>&ВТПродажи КАК ВТПродажи

Подскажите пожалуйста, где я ошибся? Спасибо!

Источник

Неверные параметры в 1С

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

1. Как установить параметр в запросе?

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

Рис. 1 Как установить параметр в запросе «Красный»

Рис. 2 Как установить параметр в запросе «Желтый»

Рис. 3 Как установить параметр в запросе «Зеленый»

Можно увидеть, что, по факту, все эти запросы одинаковые и разность только в цвете. Это-то и есть наш параметр – та переменная, которую не хотелось бы каждый раз повторять. В вышеуказанном примере параметр – это цвет, дадим ему имя «ВыбранныйЦвет» и поменяем значения цветов на эту переменную внутри запроса. А для того чтобы указать, что это именно параметр, нужно приписать перед именем амперсанд «&», тогда мы сможем задать параметр в запросе:

Рис. 4 Как задать параметр в запросе «ВыбранныйЦвет»

После этой процедуры пробуем выполнить наш запрос, результат будет пустым и выглядеть так:

Рис. 5 Результат неверного параметра в запросе пустой

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

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

Система 1С уже узнала параметр внутри запроса и выделила его в соответствующей секции, но пока без значений. Меняем пустое значение запроса, например, на значение «Жёлтый».

Рис. 7 Смена пустого значения запроса на «Желтый»

Теперь запрос выполнится! Аналогично можно заполнить оставшиеся значения. Так при помощи параметра можно в одном и том же запросе получать результаты, которые отличаются. То есть, главная функция параметров внутри запросов – делать их более обобщёнными. Это особенно актуально в сложных запросах, так как достаточно будет только изменить сам параметр, не меняя весь запрос.

2. Функция параметра «Ссылка»

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

Рис. 8 Ограничение для параметра – значение по ссылке

Наш параметр «ВыбранныйЦвет» из строки превратился в ссылку на какой-то элемент внутри справочника «Цвета», поэтому у пользователя есть возможность изменить параметр и его тип:

Рис. 9 Изменения типа параметра в 1С

После этого, в момент, когда ведётся выбор значения данного параметра, перед нами появится выпадающий список с перечнем цветов – это функция параметра ссылки.

3. Параметр «Дата»

Допустим, нужен запрос, который будет выбирать заказы клиентов в определённый период. Данный период будет иметь две границы – «НачалоИнтервала» и «КонецИнтервала».

Рис. 10 Параметр «Дата»

Аналогично выполняем данный запрос и видим, что 1С уже распознала, что у данного параметра тип «Дата». Пусть нам нужны заказы за январь 2014 года, тогда получим:

Рис. 11 Пример запроса по параметру «Дата»

Результат запроса с параметром «Дата» будет выглядеть следующим образом:

Рис. 12 Результат запроса с параметром «Дата»

В данной статье были рассмотрены параметры в системе 1С, видов параметр внутри запроса, параметр с типом «Дата», параметры с типом «Ссылка», аналогично проводится работа с параметрами в списках таблиц и таблиц со значениями. Ошибка в них возникает в случае задания невозможного названия, типа, их несоответствий, пунктуационных ошибок в коде программы.

Источник

Тип не может быть выбран в запросе

Тип не может быть выбран в запросе

Ошибка при вызове возникает в запросе, когда тип не может быть выбран в качестве источника данных (таблицы), либо не инициализирован в процессе выборки из временной таблицы. Значит вы пытаетесь загрузить таблицу значений в запрос 1С.

Полный текст ошибки:

Сопутствующий ошибке код:

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

Например:

Запрос.УстановитьПараметр(«ТЗДеньги», Новый ТаблицаЗначений);

Сам текст запроса:

Ошибка возникает в версиях 8.2 и 8.3 платформы 1С.

Причина ошибки:

Не инициализированные типы колонок в таблице значений.

Ошибка может проявится при значениях в таблице, которые не могут быть выбраны: объект Картинка, Диаграмма, Шрифт и прочие интерфейсные, либо не ссылочные типы.

Решение

Верная инициализация, каждой колонки в таблице значений:

Если колонка должна содержать несколько типов, тогда используйте другой вариант инициализации ОписаниеТипов:

Основное требование — точное указание для всех колонок.

Также смотрите про статью про тип «ЛюбаяСсылка»

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

«Неверные параметры Сумма», возникает, в случае хотя бы одно из значений в переданной таблице значений равно Null.

Реклама — двигатель всеобщей дебилизации населения.

Источник

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

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

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

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

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

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

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

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

Источник

Таблица значений в запросе

Подскажите как правильно использовать ТЗ в запросе?
Параметры ввожу тут:
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
КонецДня = Параметры.НаКакуюДату;
РеквТЗ.Параметры.УстановитьЗначениеПараметра(«НаДату», КонецДня);
РеквТЗ.Параметры.УстановитьЗначениеПараметра(«НаСкладе», Параметры.СодержитСклад);
РеквТЗ.Параметры.УстановитьЗначениеПараметра(«ТЗУчета», Параметры.ТЗУчета);
КонецПроцедуры

Выбрать
* Поместить ТЗУчета
ИЗ &ТЗУчета КАК ТЗУчета; //Тут ошибку выдает у &ТЗУчета

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

Вот так попробовал
Процедура ПриОткрытии(Отказ)

Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = «ВЫБРАТЬ * ПОМЕСТИТЬ ТЗ ИЗ &ТЗ КАК ТЗ»;
Запрос.УстановитьПараметр(«ТЗ», Параметры.ТЗУчета);
Запрос.Выполнить();

КонецПроцедуры
Но выдает ошибку:
<ОбщаяФорма.ПодборМатериалов1.Форма(89)>: Ошибка при вызове метода контекста (Выполнить)
Результат = Запрос.Выполнить().Выбрать();
по причине:
<(7, 2)>: Таблица не найдена «ТЗ»
>ТЗ

Такой взял пример:
Можно ли в запросе, в качестве источника данных, использовать таблицу значений?

Да. Это можно сделать с помощью временных таблиц:

// Сначала помещаем ТЗ во временную таблицу
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = «ВЫБРАТЬ * ПОМЕСТИТЬ ТЗ ИЗ &ТЗ КАК ТЗ»;
Запрос.УстановитьПараметр(«ТЗ», ТЗ);
Запрос.Выполнить();
// Теперь ТЗ можно использовать в запросе:
Запрос.Текст = »
|ВЫБРАТЬ
| ТЗ.Номенклатура,
| Остатки.КоличествоОстаток
|ИЗ
| ТЗ
| ЛЕВОЕ СОЕДИНЕНИЕ
| РегистрНакопления.ТоварыНаСкладах.Остатки() КАК Остатки
| ПО
| ТЗ.Номенклатура=Остатки.Номенклатура»;

Но что то у меня не катит.

Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = «ВЫБРАТЬ * ПОМЕСТИТЬ ТЗ ИЗ &ТЗ КАК ТЗ»;
Запрос.УстановитьПараметр(«ТЗ», ТЗ);
Запрос.Выполнить();
// Теперь ТЗ можно использовать в запросе:
Запрос.Текст = »
|ВЫБРАТЬ
| ТЗ.Номенклатура,
| Остатки.КоличествоОстаток
|ИЗ
| ТЗ
| ЛЕВОЕ СОЕДИНЕНИЕ
| РегистрНакопления.ТоварыНаСкладах.Остатки() КАК Остатки
| ПО
| ТЗ.Номенклатура=Остатки.Номенклатура»;

ТипизированнаяТЗ = Новый ТаблицаЗначений;
Для й=1 По Тз.Количество() Цикл ТипизированнаяТЗ.Добавить(); //Создаем строки
КонецЦикла;

ДЗТипов = Новый ДеревоЗначений;
ДЗТипов.Колонки.Добавить(«ИмяКолонки»);
ДЗТипов.Колонки.Добавить(«ТипЗначений»);

Для Каждого Колонка из Тз.Колонки Цикл
СтрокаКолонки = ДЗТипов.Строки.Добавить();
СтрокаКолонки.ИмяКолонки = Колонка.Имя;

ТекСТрокаТипа = СтрокаКолонки.Строки.Добавить();
ТекСТрокаТипа.ИмяКолонки = Колонка.Имя; //Заполняется для красоты
ТекСТрокаТипа.ТипЗначений = ТипЗнч(тз[0][Колонка.Имя]);
Для Каждого СтокаТЗ из Тз Цикл
ТекТип = ТипЗнч(СтокаТЗ[Колонка.Имя]);
Если НЕ ТекТип = ТекСТрокаТипа.ТипЗначений Тогда
Если СтрокаКолонки.Строки.Найти(ТекТип, «ТипЗначений»)=Неопределено Тогда
ТекСТрокаТипа = СтрокаКолонки.Строки.Добавить();
ТекСТрокаТипа.ИмяКолонки = Колонка.Имя;//Заполняется для красоты
ТекСТрокаТипа.ТипЗначений = ТекТип;
КонецЕслИ;
КонецЕслИ;
КонецЦикла;

МассивТипов = СтрокаКолонки.Строки.ВыгрузитьКолонку(«ТипЗначений»);
ТипизированнаяТЗ.Колонки.Добавить(Колонка.Имя, Новый ОписаниеТипов(МассивТипов),Колонка.Заголовок);
ТипизированнаяТЗ.ЗагрузитьКолонку(Тз.ВыгрузитьКолонку(Колонка),Колонка.Имя);
КонецЦикла;

Источник