Selection date question

[Lerebours, Jose]

John Posted:

> > > [ snip ]
> >
> > Boy, you are busy!
> >
> > Well, I would venture to suggest that this can be easily
> > solved if you TAG your records with a "stamp" that will
> > make them unique from user to user, or even from time
> > the operation was started.
> >
> > This is what I would do with minimum change to what
> > you have:
> >
> > 1.  Combine your 3 options into one.  No need for three
> >     menu options
> >
> > 2.  Create a STAMP made up of user ID, Date and Time or
> >     anything that will make a unique key
> >
> >
> >       STAMP="`logname` `date +%Y%m%d%H%M%S"
> >
> > 3.  Run your report/clerk passing "$STAMP" using
> >     filePro standard arguments (-r -ry ...)
> >
> > 4.  Modify programs to use @p? to match passed parameter
> >     with recorded STAMP and select/print only matching
> >     records.
> >
> > The program responsible for collecting the date range
> > will use the STAMP to identify the selection criteria.
> >
> > Once you print the record, you can remove the record or
> > set a `cron` to erase temporary files each night.
> >
> > Of course, you need to change your maps to add a field
> > where the STAMP will be kept.
> >
> > You will need to modify your selection process on the
> > final report (the printing report process) to select
> > records based on the STAMP.
> >
> > Hope this helps!
> >
> 
> Boy, Jose, I am busy, but not too busy to disagree with you, 
> sorry. Your
> method here is very arcane, overly complicated and invasive 
> in that you have
> to add fields to files... My solution was dead simple, took 
> about 6 minutes
> to write and implement. Don is welcome to use (or try should 
> I say) your
> method, but I hope he waits until I can find the code I'm 
> taking about. Take
> no offense, please, but it is far easier and dare I say it, elegant.
> 
> John
> 

It is elegant and easier and I take no offense.  However, I do
believe that easier is not better.  I am used to thinking that I
will have several hundred users wanting to do the same thing
and half the story is what is really known (there is always more
to the story) and I rather work a bit harder but do it once.

Invasive?  Since when a "developer" should concern himself with 
the feelings of a file when additional fields are needed?  
You make it sound very political and even suggest that one should
stay away from adding fields to a file.  This is a temporary
processing/holding file we are talking about, not one that will
for ever expand on HD usage.

Don, John suggestion is easier and more elegant and most importantly,
it is not invasive. Do not forget to:

1. Copy any indexes to qualifier if used for printing report.  
2. Make sure you change any lookup out of your reporting programs to 
   match the original qualifiers if applicable.
3. Change your data processing reports to write to newly created qualifier
4. Make sure user does not attempt to print same report twice or more at
   the same time just because he wants to see multiple date ranges or for
   different customers, vendors, products, etc ...
5. Make sure users do not log in more than once and have others attempt to
   print the same report at once ... 
6. Make sure you do not use a "departmental user ID (sales)" where said
   report may be printed
7. In short, the user ID must be as unique as DNA and the report should
   behave as a 'single user mode - one copy at a time' per user.

Like I said, easier is not better!

You often find yourself in situations that are simply out of your control.
As a developer, the one thing you can control is how you write your
applications, modules, programs ... I would suggest, do it so that you do
not need to come back to is simply because you wanted to get in and out
and as fast and as easy as possible the first time.

Regards;


Jose Lerebours