At 01:55 PM 22/11/2004 +0200, you wrote:

> >
>Well, point is, however, to use it with input parameters, which filters
>data much :
>typical sample would be to get interval of 100 accounts balance for
>declared date,
>or certain customer data of orders:
>using first sample, there would be input : accounts interval, date, an
>procedure body would look something like :
>
>for select acc from .... where acc between acc1 and acc2
> into :acc do
> select balance from p_get_balance(acc,:when_date) into :balance suspend;

Yes. That's what I meant.

>As far as in views input parameters are not possible, i think this is
>fastest way to get results.

You don't *need* input parameters for views, since you use WHERE and ORDER
BY clauses directly with them, as you do with tables. The advantage of a
view is that indexes will be used in the retrieval.

> >>>You will cause the entire set to
> >>>be generated and this *will* be slow.
>
>It is ok with me, because set would be no bigger than 100 rows
>(ordering/grouping/filtering fast), but what is bad : READS from table are
>doubled/tripled.

Huh? The number of reads done inside a SP depends on the statements you ask
it to execute - just as in any SELECT request.

>It looks that procedure does not cache result set, but strangely somehow
>recalculates it on runtime.

Exactly. A stored procedure runs in its entirety each time it is
called. So you should pass input parameters that are used in a WHERE
clause inside the SP to restrict the number of rows that the procedure has
to touch.

./heLen