Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

Доброе утро! Хочу осуществить на практике примерно следующее...
Нужно сделать отчет, в котором будет несколько уровней поиска, то есть, нажимаю "кнопку" выходит список возможных вариантов поиска, допустим " ПО, ТО, Дата", после выбора пошел следующий уровень, если "дата" - то "дата установки" либо скажем "дата ввода ТО", затем уже вводим конкретное значение либо выбираем из списка уже загнанных значений, примерно также и с остальным...
Теперь вопрос, как мне осуществить такого рода последовательность?

почему это именно уровни поиска?
поиск должен отрабатывать в итоге сколько раз, один? в самом конце?
то есть можно говорить просто о последовательности выбора способа поиска?
если так - то эту последовательно можно сделать в действии.
на первом шаге - выбираем способ, потом прыгаем на нужный шаг, там выбираем уже что то конкретное.
в итоге из одной точки начала должны выйти на запуск того или иного отчета (ну или одного отчета, но с разными параметрами.. это как пойдет)

Мы в свое время отказались от данной идеи
т.е. задача - если первая выборка/отчет вернула что-то > запустить вторую/отчет расширенную - если опять что-то есть > запустить другое/отчет или сделать ветвление...
короче - гонять массивы id по связанным отчетам - очень тормозная и некрасивая штука - когда они по каждой строке нового отчета начинают мельтешить...

может благодаря нашей модели данных - но нам оказалось достаточно одного отчета по разным типам объектов построенного по принципу получается быстро и круто, а все критерии для всех уровней или для каждого в отдельности задаем на закладке аргументы
ветвления никакого - зато миллион данных от разных типов объектов и в одном запросе/отчете

ps
на практике, у нас по крайней мере, используется только один тип отчета - пользовательский=сорость/наполненность, вся красота внешних документов включая их создание - только через vbscript
стандартный сервис Лоции для этих целей -....., есть конечно..., но... короче мы не можем его использовать из эстетических соображений

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

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

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

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

ps
тебе нужно отойди от обычного программирования - и смотреть на обработку данных как SQL программисту... как говорят у нас в... это две Большие разницы