Bug in *report with -fp

[John Esak]

 Have to come down on the side with Bruce... backward compatibility
overrides anything... problem or no. If there is a consensus that something
is really *very* bad about a behavior, the simple thing to do is get FP Tech
to change it, and as Bruce said put in an environment var that would let
anyone using it the broken way... keep doing that. :-(  In any case, I
believe this is the way FP Tech has always worked since day one anyway. I
can't remember a time when this was different... except for the MID() change
that Bill Campbell would bring up because it bit him very early on in
filePro early development days.  Other than that, I think there are env vars
for backward compat... up the ying yang. :-)

I will say this... running a -fp prc-name that is wrong and not having it
run... can be very frustrating if you don't know to expect this behavior...
If you do, it is no problem at all, just fix the misnomer and your off to
the races again.

John


> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> Behalf Of Bruce Easton
> Sent: Wednesday, March 14, 2007 11:16 AM
> To: filepro-list at lists.celestial.com
> Subject: RE: Bug in *report with -fp
>
>
> Bill Akers wrote Wednesday, March 14, 2007 10:14 AM:
> [..]
> > In effect, you are replacing the normal report format with a
> > processing only format that generates no report but performs some other
> > type of procedure..
>
> Well that's your take on it - and I think it's a good one.  But one could
> just as easily say that in effect you are simply running processing and
> using no format at all - not replacing anything. More
> importantly, someone
> who started using this flag and observing its present behavior certainly
> might not see it as you do.  Thus my concern for backward compatibility.
>
> > Ergo, if fp complains about a non-existent output
> > format it should, by default, assign the same behavior to  a
> > non-existent processing table that is used as the output format.
>
> That would have been a nice behavior from the start, but that's not
> the way it has been, thus my concern for backward compatibility.
>
> > It is difficult to believe that anyone is running a routine which
> > generates no report and performs no processing, on purpose. Therefore,
> > the argument that someone's programming would be somehow corrupted
> [..]
>
> Well, mabye you missed my example involving how a cron job, where if
> the behavior were to switch to generating an error, and the developer
> didn't consider the changed behavior as a potential problem, they
> might spend hours trying to find out why their cron job got hung.  I
> admit that my example is what many might see as not a conventional
> use of filepro, but we have often seen these kinds of techniques
> implemented.  And that's why, even though I really don't consider
> this to be a big issue, I think it's very important to always consider
> backward compatibility when changing any existing behavior.
>
> And yes, if the behavior changes, I would expect an environ. variable
> to allow the current behavior - even if the current behavior didn't
> make any sense to me - all for the sake of guess what - backward
> compatibility.
>
> Bruce
>
> Bruce Easton
> STN, Inc.
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list