Helen Borrie wrote:

>
>
>Don't order the output of a SP, do the ordering inside it. This way,
>indexes can be used:
>
>for select name,surname from people
>order by surname, name
>into :name,:surname do suspend;
>
>
>
>
>
>SPs are not views, so don't define SPs with the intention of selecting them
>with WHERE, ORDER BY or GROUP BY clauses. You will cause the entire set to
>be generated and this *will* be slow.
>
>In fact, for the above example, a view selected with an ORDER BY clause, or
>just a simple dsql statement, will be much faster. Don't use SSPs to
>replace what DSQL does easily.
>
>
>
>

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;

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

>>>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.
It looks that procedure does not cache result set, but strangely somehow recalculates it on runtime.