× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: 4 - subfiles
  • From: "Dan Bale" <dbale@xxxxxxxxxxx>
  • Date: Mon, 8 Nov 1999 10:28:02 -0500



Booth,

(This is late because it came back as "undeliverable" after I left Friday.)

You are "tilting at windmills".  ;-)

Four separate subfiles?  What happens when you want to change something on the
display?  Are you going to have to maintain 4 subfile records and/or 4 subfile
control records?  Yecchhhh!  What if you add a couple more logical views?  You
see where I'm going with this...

And, while your phonebook application would seem to be fairly static, what if
you maintain the data?  Add records, modify records, delete records?  Will you
reload all four subfiles again?  For each user that uses the app?  I realize
you're probably talking about an app that only _you_ will use and have static
data, so if you were to do this, you understand that this is strictly a "quick
and dirty" approach.

You said you're not very good at subfiles.  Listen, I haven't written a subfile
app from scratch in a _very_ long time and I would hate to try now.  I have
several templates that I choose from.  In fact, a year ago I implemented the
four logical view subfile (one subfile, not four) you're talking about for a
specific customer's application.  It is a page-at-a-time subfile (SFLPAG =
SFLSIZ) where the user can enter an option to view, change, delete, print, etc.
It works great and there are 50 or so users using it.

When I first learned subfiles, I was definately not in the page-at-a-time camp;
it may have been a company standard way back when, can't remember.  But now,
page-at-a-time is the option I usually consider first.

I guess, IMHO, that I would recommend that you do it "right" with this
relatively simple application and learn the skills so that you'll be able to
pull your template out of your bag of tricks when a customer asks for something
that calls for it.

- Dan Bale


boothm@earth.goddard.edu wrote:

Here's a subfile question.  I'm not very good with them.  I have a display
screen showing a subfile with 4 fields.  Each field is the key to a
logical file so there are 4 logical files in the F-specs.  For clarity,
lets call the fields LastName, FirstName, ExtNbr, DeptName.  I want the
user to be able to display any one of the 4 logical files.  I know the
file will never grow beyond 999 because the ExtNbr field is 3/0, and
because there's only about 150 extensions now, anyway.   Every time the
user selects another logical to display I clear the subfile and  reload
the entire file to the subfile.  With a dozen test records I'm getting
sub-second reloads.  Now, as the number of records increases it seems to
me that reload times will increase.  Still, I know that 5000 records load
in 11 or 12 seconds so the time for about 200 records will probably be a
second or two.

However, it occurs to me that having loaded the subfile, I shouldn't need
to read the data file again.  I am thinking there must be an easy way to
save the subfile in case it is needed again, instead of just clearing it,
or am I tilting at windmills?





+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2024 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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.