RE: Even more embedded SQL....

[qsrvbas@xxxxxxxxxxxx]

Alan:

I'm not clear on the full requirements. Although you've stated a 15,000 row 
size, it isn't clear whether these rows represent the total size of the 
table(s) or that there are 15,000 rows expected _after_ a WHERE clause is 
applied.

Charles Wilt mentioned a separation, and I think that's an excellent idea to 
consider.

Break it into at least two and possibly three parts. The first part populates a 
work area with 15,000 rows. It can be a user space, a memory allocation or even 
a temporary work file. You don't have enough rows to be concerned with only 
15,000. The second part sorts those rows (and needs no WHERE clause). Any sort 
will be fast enough with such a small table. The third part performs any 
positioning and retrieval.

The first part would be executed once. The other two would be executed as 
needed.

An additional issue would involve any updating. If users do updates, then the 
updates must be applied to the work rows as well as the live rows.

Tom Liotta

rpg400-l-request@xxxxxxxxxxxx wrote:

>   7. Re: Even more embedded SQL.... (Alan Shore)
> Johnny - thanks for your reply, but I am betting that you do a load all
> sub-file, and NOT a page at a time sub-file, which is what I need for
> 15,000 or more records.
>
> I'm pretty sure that what I need to load page at a time is
> FIND NEXT
> FIND CURRENT
> FIND RELATIVE
> for things as Page up, Page Down etc.
> but I'm not too sure how to do a position to within the sub-file using SQL