RE: Simple Display file problem

Searchable cursors was a side thought related to SQL and display programs. 
 My other point was to show something you can not do straight forward with 
RLA--a join criteria that was not an equal sign. 

I've had to implement my own binary search on a cursor to perform a 
position-to function.  I didn't want to show a subset of the data.  I 
wanted to window the cursor.  Other databases have this, so it would be 
cool if the 400 had it as well.

I agree with Alan on his points for SQL vs. RLA.  Get comfortable writing 
programs with SQL so you have a crossplatform skill.

Mark

<Joe wrote>
Yeah, that's very cool.  It's a set-based function and it's the kind of
thing SQL is made for.  It's also just a tiny bit scary; you have an
unqualified join which means you're creating a Cartesian product.  I'm
not
sure if the "WHERE" clause is applied BEFORE or AFTER the JOIN is
applied.
Theoretically you're calculating up to 10 billion distances every time
you
do this.  But realistically the number is probably far smaller, and I
guess
if you think about it, how else are you going to do it?
</Joe>

<Alan wrote>
The solution here is Ops Nav. Put the SQL into a Run SQL script and then
request a Visual Explain and it will show you exactly how it plans to
run the query. 

How SQL decides to run the query has nothing to do with how you put it
in. That's why I always run in Ops Nav on any complicated query to make
sure it is not doing something funny. 

Make sure that you use V5R3 and V5R4 version of Client Access. They have
much, much improved SQL functions. I believe both run on V5R2 OS/400 up.

Also, on the question of position to SQL result couldn't you do a
subquery to return the mileage result and then select the result based
on a mileage range that is input? 

SQL does support what you want, just not the way you thinking about it.
</Alan>