> >It's been my experience that if I have a stored procedure which returns
> >rows in a particular order and perform a SELECT on this procedure, the
> >row order of the SELECT matches that of the procedure. E.g.:
> >
> >What I would like to know, is this behavior documented or is it just a
> >random occurence? I know that when SELECTing from tables/views I should
> >always use ORDER BY if I need the records sorted in a particular order,
> >but is the same thing true for selecting from stored procedures?
>
> Rows are returned in the exact order they are sent, i.e., the first
> SUSPEND sends the first row to the buffer, the second SUSPEND sends the
> second row, and so on.

*Returned* is obvious. But if I *read* these returned rows and output
them again, is it a documented behavior that the output will reflect the
ordering from the stored procedure?

> It is much more efficient to have your SSP work with an ordered set, as
> the FOR SELECT inside the SP can use indexes. Ordering the set of
> virtual output is a sloooooow process and of course there are no indexes
> to call on.

Of course. But that's not the issue here. The issue is, if my procedure
returns a growing sequence, can I depend on it always being growing or
should I make sure by an explicit order outside of the procedure?

Thanks,

Pepa