I agree (and am very conscious of) with the fact that the only way to guarantee a result ordered is with the ORDER BY clause.
That said, what I don't really understand is SQL using an index for reporting the RRN(). One would imagine that kind of things would be better doing a table scan.
IBM Certified Systems Expert
eServer i5 iSeries Technical Solutions
--- On Sat, 7/26/08, midrange-l-request@xxxxxxxxxxxx <midrange-l-request@xxxxxxxxxxxx> wrote:
date: Sat, 26 Jul 2008 00:13:35 -0400
from: Terrence Enger <tenger@xxxxxxxxxxxxxxxx>
subject: Re: SQL - RRN() not in order
Let me remind people--I confess, myself included--that if
results in a specific order, you must specify that order
Even selecting from a keyed logical does not guarantee any
This is hard to remember because it so often happens that
will choose a strategy which returns rows in the
"right" order by
On Fri, 2008-07-25 at 07:10 -0700, Luis Rodriguez wrote:
Hi List,least for me) results with SQL RRN:
Running some tests (V5R3) I found this strange (at
(FILE is a (DDS) file with no index and zero deletedrecords)
SQL decided to use an index (LF).
Select RRN(file) from FILE;
RRN ( file )
Select RRN(file), file.* from FILE;
RRN ( file ) (Fields...)
Even this sorts the output by RRN():
Select RRN(file) from FILE WHERE RRN(file) < 700;
Running the sentence under debug (STRDBG) shows that
Moreover, the selected index is a join file(3 Files!!)
My question is: Why does RRN() needs an index?.
I'm just curious why this is so.
This is not giving any problem for me right now,