IN фильтр в while select запросе?

[kitty]

Пользователь выбирает в мультиселекте набор значений.
Потом в коде есть while select , который надо отфильтровать по этому переданному набору значений.

Я могу сделать врем таблицу,заполнить этим набором значений и потом join к while-select.

Появились ли какие-то новые/более симпатичные способы, как это можно выполнить в AX2012?


AX2012 R2

[gl00mie]

Query?..

[kitty]

спасибо, понятно, раз новых нет, старыми костылями придется пользоваться(

[Weez]

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

[kitty]

тк
1) while-select уже существует и переписывать существующую логику в query только для того, чтобы добавить доп условие на 1 поле - имхо, не умно
2) критерии из этого while-select только с extended query ranges можно попробовать запихнуть в query, но по пути еще можно огрести много отладки и багов ....

[Napalm]

Цитата:

Сообщение от gl00mie

Query?..

Цитата:

Сообщение от Weez

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

Query плохое решение.

[Weez]

Цитата:

Сообщение от Napalm

Query плохое решение.

Аргументы?

[Napalm]

Цитата:

Сообщение от Weez

Аргументы?

Работает только для небольшого количества записей.

[Weez]

Цитата:

Сообщение от Napalm

Работает только для небольшого количества записей.

Неправда, все работает абсолютно идентично while select, только удобней с точки зрения поддержки и изменения запроса. За редким исключением.

[AndyD]

Только, делайте временную таблицу TempDB

[S.Kuskov]

Выборка произвольных записей одним запросом

[gl00mie]

См. пример по ссылке:

Цитата:

Сообщение от S.Kuskov

Выборка произвольных записей одним запросом

Код, выполняющий выборку с Query, получается совершенно не зависящим от того, сколько записей выбрано пользователем: 1, 10 или 1000. Все эти заморочки ложатся на код, который готовит Query: в каких-то случаях он может добавить фильтры прямо в запрос, причем добавить их довольно много, с учетом ограничения на результирующую длину SQL-запроса, в каких-то - может при-join-нить RecordReferenceList_RU. В случае же select'а в коде X++ такой гибкости нет: либо явно зашитое copy-paste'ом в код число фильтров, либо join с дополнительной таблицей.

[Napalm]

Цитата:

Сообщение от gl00mie

См. пример по ссылке:Код, выполняющий выборку с Query, получается совершенно не зависящим от того, сколько записей выбрано пользователем: 1, 10 или 1000. Все эти заморочки ложатся на код, который готовит Query: в каких-то случаях он может добавить фильтры прямо в запрос, причем добавить их довольно много, с учетом ограничения на результирующую длину SQL-запроса, в каких-то - может при-join-нить RecordReferenceList_RU. В случае же select'а в коде X++ такой гибкости нет: либо явно зашитое copy-paste'ом в код число фильтров, либо join с дополнительной таблицей.

Полное непонимание вопроса.

[mazzy]

Цитата:

Сообщение от Napalm

Полное непонимание вопроса.

Бггг!!! Napalm, жжоте. Тупо жжоте.

Да, надо разделить вопрос:
= Query vs while select
= in vs range

Query надо использовать ВСЕГДА!
По построению - Query, это программный объект, который позволяет программисту при помощи методов строить и менять запрос. А также (!) использовать переменные условия на переменное число полей. UPD: в том числе добавлять таблицы и условия может и пользователь (!!!!), если ему дали такие права, а программист предоставил соответствующий диалог (как правило, пара методов).

while select - немодифицируемый оператор языка. программист не может изменить запрос, написанный при помощи while select. Делать "переменный" или "модифицируемый" while select - это ссать против ветра.

======================
in - отсутствует в Аксапте
в аксапте присуствует range, сводящийся к OR, AND, NOT

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

===============================

Цитата:

Сообщение от kitty

тк
1) while-select уже существует и переписывать существующую логику в query только для того, чтобы добавить доп условие на 1 поле - имхо, не умно

Бгггг.... Я бы после такого заявления уволил

Цитата:

Сообщение от Napalm

Query плохое решение.

Бггг... туда же

Цитата:

Сообщение от Cardagant

Query и правда не подойдёт, если количество OR может быть очень большим.

А не надо использовать query для большого числа OR (как и для большого числа элементов в IN)
даже до того, как вы упретесь в ограничение длины строки, SQL перестанет оптимизировать план запроса для очень большого числа условий.

странно даже, вроде в реальной жизни никто ножом дрова не колет... а колуном не затачивает карандаши... а с select и Query - полно желающих.

[Napalm]

Цитата:

Сообщение от mazzy

Query надо использовать ВСЕГДА!

LOL.

Цитата:

Сообщение от mazzy

Бгггг.... Я бы после такого заявления уволил

Цитата:

Сообщение от mazzy

Бггг... туда же

Я бы к такому "знатоку" работать не пошел.

[Cardagant]

Цитата:

Сообщение от mazzy

Бггг!!! Napalm, жжоте. Тупо жжоте.
А не надо использовать query для большого числа OR (как и для большого числа элементов в IN)
даже до того, как вы упретесь в ограничение длины строки, SQL перестанет оптимизировать план запроса для очень большого числа условий..

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

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

[gl00mie]

«У нас в клубе принято джентльменам верить на слово!» ©