Filtering / Redesigning Reports methodology

Question

Greetings All!
I need your advice on this issue:
We need to implement something like Access Database crosstab / Excel pivot table report
We have PL/SQL function which creates query for this report
Unfortunately Interactive Report cannot take PL/SQL body as datasource
We tried it with regular ApEx SQL Report and it works.
Now we need to create filtering and grouping GUI
And here the question goes:
Should we
a) create form based on database table which will hold all settings for all reports (and fields which users select to view in report and build filters for - with possible ability to save settings) and somehow - thru PL/SQL body, getting session id? - change the source of SQL Report for THAT user session which requested this report layout (and there are a lot of sessions possible)
- this would be universal for any report but is it worth doing?
or
b) create simple dropdowns / list boxes / checkboxes or a Wizard similar to Excel pivot table wizard at the same page where SQL Report resides and simply read these ~..boxes and rewrite report's query thru PL/SQL body here.
- this would be pretty simple (or there will be a lot of coding?) but should be repeated for every report from scratch...
So I'm in doubt which way is better...

Answer 1

My problem is that I should allow users to create CROSSTAB on any field thay choose, so I need best practice:
1) how to organize GUI for users where they could select row/column/sum fields
a) universal form (for any report) based on table which stores saved settings between sessions
b) checkboxes/listboxes hand-made for every single report
c) ...?
2) how to change report's datasource to show results based on p.1.
for p.2 I have function that gets row/column/sum fields as parameters ans builds SQL query (string) for me
and here are your recommendations:
Jens.Gauger >Have you ever tried to to use a "Pipeline"-Function?
Not yet, thanks for example!
So Interactive Report is able to use this syntax
'SELECT ... FROM TABLE(<function name>(<param1>,<param2>...)).
and Interactive Report will magically change number of its fields at run time based on what function returns (because number and names of columns are unknown before user chooses CROSSTAB column field)?
ATD >An Interactive Report can be based on a collection
thanks for example too!
Could you please tell me which approach (pipeline on collection) is better and why?
Maybe it's important that underlying data may have millions of rows and collection will be slower (or faster) on these millions?
And I still need advice from you on p.1