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.
