Re: Display file cursor positioning -- can somebody clarify, and/or jog my memory?

I tend to do only load-all subfiles. In my experience, even if the data file is huge, some thoughtful design work up front gets load-all subfiles down to a few hundred records. No scenario I can imagine would have a user actually paging through 7000 records, let alone 70,000 or 700,000 records.

If the user is truly working randomly against a humongous file then a page-at-a-time file works reasonably well since you are going to be building the subfile repeatedly, anyway.

Anyway, that is an opinion, and I realize it is not even a popular opinion. But it has worked well in every situation I have come up against with the exception of the "'Shut up' the boss explained" scenario.

On 11/15/2012 4:20 PM, Carel Teijgeler wrote:

All I want to add, that this only applies for the first SFL page. IIRC (and
many moons has passed since that day), when on the second or third oage you
have to see which SFL age is active and do some calculations from that point.
This was on a SFL with input capable fields.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR ***********

On 15-11-2012 at 15:07 Booth Martin wrote:

One alternate solution that might be useful with the subfile is to always

advance the subfile screen so that the selected row, when

returned, is always returned at the top of the subfile (In some operations

that could mean that the file's repositioning automatically

moves the records up so that the user finds the next desired record already on

the screen.)

SF1TOP 4S 0H SFLRCDNBR(CURSOR *TOP)

That allows the problematic issue to become a feature. Maybe.