Длина Range

[Владимир Максимов]

Какое есть ограничение на длину Range (или всего Query)?

У меня сформирован список значений и надо сделать Query выводящий записи только с этими значениями. Имеется в виду

QueryBuildDataSource.addRange(fieldnum(...)).value("1,2,3,4,...")

Т.е. много значений Value (до нескольких сотен)

Допустимо делать несколько Query по очереди.

На какой длине (и длине чего - Value или Query) следует остановиться.

PS:
Про то, что временные таблицы - лучше, я в курсе. Можно ли это реализовать БЕЗ временной таблицы.

[mazzy]

вроде 250 символов.

[Garic]

побольше
MSSQL, Ax 2.5
Менее 1000 элементов - sql загибается

[Владимир Максимов]

Проблема в том, что собственно сам Range().Value() глотает значения без ограничений, но вот на этапе формирования выражения SQL у него получается примерно следующее:

(((((((((((((((((((Field=1)
OR Field=2)
OR Field=3)
OR Field=4)
...

И при некоторой длине выражения получается синтаксическая ошибка об отсутствии закрывающей скобки.

Мне непонятно в какой момент происходит это "обрезание" - в момент подстановки Range().Value() или в момент формирования окончательного выражения SELECT.

И еще, может быть можно как-то по другому ограничить выборку (не считая временных таблиц)?

Была идея по возможности задавать диапазоны (1...5,10,15...20), но непонятно, как можно отсортировать контейнер или map в которых хранится список значений.

[mazzy]

не знаю. я бы таки ориентировался на тип Range, длина которого 250 символов
не уверен, что другие варианты будут совместимы.

Владимир Максимов, я правильно понимаю, что вы хотите используя QUERY отобрать записи из СПИСКА значений? И при этом вы НЕ используете временные таблицы? может вы код сюда поместите? Очень похоже на 1Совскую терминологию.

Скорее всего вы используете не тот инструмент не в то место.

[Владимир Максимов]

Правильно поняли постановку задачи. Речь идет о формировании отчета. Очень дурацкое ТЗ к этому отчету. Отчет формируется в текстовый файл.

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

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

Если первая выборка - это довольно простой Query, то вот со второй выборкой проблемы

Проблема еще в том, что связь между предварительными и основными заказами осуществляется через дополнительное поле (не из стандартной конфигурации) в таблице SalesLine

Пока я поступаю так: в процессе сканирования основного Query запоминаю в Map все использованные коды предварительных заказав и все использованные коды строк этих предварительных заказов. И потом цикл по Map с модификацией Range исходного Query.

Но это слишком долго получается. Вот и пытаюсь как-то ускорить это безобразие.

[blokva]

Ну отсортировать то не проблемма, а вот надо ли?
А что за источник этих значений?

[Владимир Максимов]

SalesTable.Salesid - отобрать все записи с заданными значениями (список)
SalesLine.InventTransId - исключая записи с заданными значениями (список)

[mazzy]

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

с временной то таблицей намного легче было бы в трехуровневой среде нормальное взаимодействие организовать. ИМХО.

[blokva]

Или попробывать применить NotExistJoin...

[Владимир Максимов]

Да не отказывался я. Просто не привык еще за собой "мусор" оставлять. Что в Axapta постоянно происходит. А временную таблицу я воспринимаю именно как мусор, который должен быть удален по завершении отчета.

Т.е. я понимаю, что ее физически все-равно не будет в базе данных, но пока еще это для меня непривычно - раз объект есть в АОТ, то я воспринимаю этот объект как постоянный.

В АОТ и так уже достаточно реального мусора (т.е. кто-то что-то тестировал, а потом за собой не убрал). Вот и не хочется плодить лишнего.

[Владимир Максимов]

Цитата:

Или попробывать применить NotExistJoin

В данном случае это не пройдет. Глюк построителя Query в Axapta (там несколько таблиц связанных по Join). Он его просто проигнорирует. Пробовал уже.

[mazzy]

Цитата:

Изначально опубликовано Владимир Максимов
А временную таблицу я воспринимаю именно как мусор, который должен быть удален по завершении отчета.

Хм... ну дык, Аксапта и удаляет. сама и автоматически. И данные видны только в контексте переменной.

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

[Владимир Максимов]

Физическую логику работы я прекрасно понимаю.
Проблема чисто психологическая - раз что-то есть в АОТ, то это что-то постоянный объект.

Кстати, временная таблица в данном случае нормально соединится по Join с готовым Query? Речь идет о 3-х звенке. Axapata 2.5 (Вроде были какие-то замечание по поводу глюков)

[mazzy]

соединится. прозрачно для программиста.

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

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

я бы не назвал это нормальным. прозрачно.

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

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

[Владимир Максимов]

Спасибо. Завтра буду экспериментировать.

[Владимир Максимов]

Результат экспериментов:

Временная таблица не подошла по той причине, что ее можно подключать по INNER JOIN только если эта временная таблица является главной (первый DataSource). А у меня уже готовый Query и перекачивать его весь ПОД эту временную таблицу слишком утомительно.

Сделал постоянную таблицу в базе, используя ее как временную. Время выполнения сократилось в разы (приблизительно в 5 раз)

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Владимир Максимов
Проблема чисто психологическая - раз что-то есть в АОТ, то это что-то постоянный объект.

Необязательно создавать элемент AOT под временную таблицу. Если структура временной таблицы повторяет структуру одной из постоянных таблиц AOT, то можно создать переменную-временную таблицу при помощи метода setTmp()

[Wamr]

Цитата:

можно создать переменную-временную таблицу при помощи метода setTmp()

Тогда психологическая проблема удваивается вроде таблица и вроде постоянная... а данные пропадают.