Как передать результирующий запрос данных с клиента обратно в БД для доработки?

Есть форма - на которой динамически формирую запрос. По результатам простановки крыжиков, переключателей и тп
С помощью AddWhere()

По результатам - получается другой запрос. Так вот хотелось на основании полученного запроса еще кое что проделать: например отобразить агрегированные данные (но может быть и более сложная задача)

Абстрактный пример:
1) select car_num, town from bd.cars - получаем на форму список машин
2) AddWhere('color='Red'') манипуляциями на форме ограничиваем список только красными - итоговый запрос
select car_num, town from bd.cars where color='Red'
3) Хочу отобразить на форме еще и итоговое кол-во машин, их номера через запятую и тп - в разрезе городов напр такой сложный запрос:

select town, count(*) cnt, listagg (car_num,',') within group (order by car_num) lst from bd.cars where color='Red' group by town

Как это сделать менее извращенно?

P.S. Вполне возможно что вопрос не столько оракловый, сколько делфовый - но может кто и здесь сталкивался с подобным?
Задача очень похожа на передачу курсоров туда-обратно

v11.2.0.3

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

stil
Как это сделать менее извращенно?

Inline view?

Elic
stil Как это сделать менее извращенно? Inline view?

Получить текст итогового запроса - передать его текстом в процедуру

а потом через open for открыть?

Что-то вроде -
txt:='select car_num, town from bd.cars where color='Red'';

new_query:='select town, count(*) cnt, listagg (car_num,',') within group (order by car_num) lst from '&txt& ' group by town'

?

Верно понял?

stil,
на клиент, при том в делфях все давно придумано

stil,
к тому же все крыжики, переключатели и тп для настройки итогов делать не придеться

ArtNick,

если я верно понял Вы имеете ввиду стандартные девэкспрессовские фильтры, галочки и тп - то в общем случае не пойдет

1) они работают на клиенте в уже зафетченными на оного данными. Это не всегда возможно при большом кол-ве данных - проще ограничить уже в условиях запроса и все на клиента не тянуть

2) в девэкспрессе - и его гриде только стандартные галочки и фильтры - часто приходится в таких фильтровочных формах извращаться и более заковыристо - когда крыж должен добавить в запрос что нить типа

where not exists (один запрос) and exists (второй запрос). На одном гриде не уедешь

P.S. Понятно там где это не нужно - стараюсь велосипеды не изобретать

stil
Верно понял?

Возможно. Только я не понимая зачем для "отображения" нужна какая-то процедура. Это нужно делать на клиенте.

stil
Это не всегда возможно при большом кол-ве данных

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

stil
номера через запятую и тп - в разрезе городов

на чем экономим, на одном мелкочисленном поле кода города?

stil
1) они работают на клиенте в уже зафетченными на оного данными. Это не всегда возможно при большом кол-ве данных - проще ограничить уже в условиях запроса и все на клиента не тянуть

сначала фильтр, потом запрос. кстати, а своп разве отменили? хотя если имеется ввиду время получения данных, то теоретически можно натянуть такой набор фильтров, что время получения данных всё равно не устроит.

stil
2) в девэкспрессе - и его гриде только стандартные галочки и фильтры - часто приходится в таких фильтровочных формах извращаться и более заковыристо - когда крыж должен добавить в запрос что нить типа where not exists (один запрос) and exists (второй запрос). На одном гриде не уедешь

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

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