Data Selection Process for Dclerk

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
>
[mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com]
On
> Behalf Of Rodgers Hemer
> Sent: Wednesday, January 28, 2009 1:18 PM
> To: john at valar.com
> Cc: filepro-list at lists.celestial.com
> Subject: Re: Data Selection Process for Dclerk
> 
> 
> On Jan 27, 2009, at 8:11 PM, John Esak wrote:
> 
> > Yes, I have a solution.
> > On the first line of script, go into clerk and on a popup screen ask
> > the
> > questions needed to build the demand index.  Then drop to a system
> > command
> > and build the index.  Then exit clerk.  The second line of the
> > script should
> > take you back into clerk using that index.  The speed of today's
> > computers
> > would make this very viable.
> >
> > Now, do you want to know what *I* would do instead of this.  I think
> > this is
> > a fairly kludgy way to do what you want.  It will work... But it
> > lacks a
> > lot.  I would stand in a 'stand" file and bring up a browse of just
> > the
> > records desired.  Build all the processing needed in that table and
> > let them
> > go at it.  You would pretty much have to copy all the INPUT table
> > processing
> > and screens from INPUT to the new processing... Then change the real
> > fields
> > on the screen to dummies and change the appropriate parts of the
> > processing
> > including @w[ef]l* fields to the new dummies.  This is the very best
> > way to
> > maintain complete control and allows the added nicety of not having
> > to use a
> > demand index.  A good thing because what if the user changes a demand
> > indexed field to take that record *out* of the appropriate slection
> > set for
> > that demand index.  With the method I'm suggesting it would
> > dissappear from
> > the browse as it should.  In the other more kludgy method it would
> > still be
> > visible when it really shouldn't be.
> >>
> John:
> 
> Thanks for the very useful solutions.  I am going to use the first
> immediately and then
> consider the second.  My concern as to the second solution has to do
> with the process
> that would have to be rewritten.  It is a header file already doing a
> lot of work with
> a detail file using dummy fields, and it has many @keyx processes
> controlling access
> and processing for both files.  The gain may not equal the pain.
> 
> Thanks again,
> 
> Rodgers Hemer

Just an addendum to what John has suggested.  Instead of recreating all of
the screens and processing, one can read the record # of the record to
update.  The system out to the file using clerk and use @once processing to
move to that specific record.

When finished, the program will return to the main processing and then
return to the browse.

I am currently doing something like this for one client when an initial
record is entered and the operator wants to continue entering information
about this person which is not available when entering a new client.

Again, speed of the systems today will make this process very fast.


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net