Data Selection Process for Dclerk

[Rodgers Hemer]

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