• Subject: Re: subfile size
  • From: boothm@xxxxxxx
  • Date: Tue, 12 Oct 1999 00:13:18 -0400

I'd agree with avoiding 9000 record subfiles but I have found many files
are less that 2500 records.  2500 records load surprisingly fast; like
under 2 seconds many times.  I'd differ with you Larry on the number 50. 
I'd load either way more, or just a screen at a time.  50 is neither fish
nor fowl imho.

It seems to me that where a user will be looking and inquiring into medium
and small files all during the day then those files must be considered
reasonable candidates for fully loaded subfile with a scroll bar.  (The
green screen scroll bar is really neat if you haven't seen it.) 

My experience is that at somewhere around 2,000 to 2,500 records the file
becomes to sensitive for scrolling so larger than that is of no value to
the user  and you might as well give him a page at a time.


In <38029248.DD74E5D5@ibm.net>, on 10/11/99 
   at 09:43 PM, Larry Bolhuis <lbolhui@ibm.net> said:

>Umm, can I ask a real basic question?  Irregardless of the fact that you
>CAN put 9999 records into a SFL, why would you Want to?  We have always
>set some 'line in the sand' (normally less than 50) after which we let
>the users actions determine if more records are needed.  

-- 
-----------------------------------------------------------
boothm@ibm.net
Booth Martin
-----------------------------------------------------------

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact [javascript protected email address].