Re: SFL More

[Dan <dan27649@xxxxxxxxx>]

Booth, we agree that developers of subfile programs need to consider how
much data to load, and add filtering options to create a more "intelligent"
or "useful" list.  Unfortunately, the vast majority of subfile programs
that cross my path rarely do this.  The standard in my current shop is to
use "position to" fields to set the top of the subfile, and load a page at
a time, adding records at each Page Down.

Regardless, the opinions I expressed in the earlier response still stand.

- Dan

On Tue, Aug 1, 2017 at 3:11 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

> As an aside, some years ago, as I looked at other platforms and how they
> handled subfiles I noticed that rarely is a subfile greater than a couple
> of hundred rows.  When I wrapped my head around that I recognized no one is
> going to willingly page through 6000 rows. Ever.  That made me rethink work
> flow and made me start watching what these other platforms do when there
> are millions of records available.  Now, when a subfile is likely to exceed
> 300 records I step back and look to inserting a filter to cut down the
> records to be processed.  Once I changed my attitude about the 9999 row
> subfile limit I found my programs were simpler to use, less training
> needed, and markedly improved response times.  Also, writing only load-all
> subfiles is just a whole lot less code.