Feature Request: ORIG()

[John Esak]

As Ken mentioned to me recently, you can probably build a 999 element array
over any file no matter how many fields are in it.  Just don't access any
array element past the last field in the file. How do you know the last
field number??  You could open() the map file and determine it from that...
(number of lines in the file minus 1.)  Among some other even stranger
things.  At least it is a workaround until your feature request is granted.
:-)

JE


> -----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 Jay R. Ashworth
> Sent: Wednesday, January 17, 2007 12:02 PM
> To: filepro-list at lists.celestial.com
> Subject: Feature Request: ORIG()
>
>
> On Wed, Jan 17, 2007 at 06:43:34AM -0800, Jeff Harrison wrote:
> > > >>I believe that he wants to compare the current values
> > > to the original values - if you want to do that at the
> > > time the record is saved, then I believe that you do
> > > need an array to store the original values.
> > > >>>
> > >
> > > The older Filepro manual has a solution for this that doesn't use a
> > > lot of code.
> > >
> > > What you do is create a qualifier for the file. On entering update
> > > copy the record to the qualified file and record the record number
> > > of that record in a dummy field. When saving the record run a loop
> > > to compare each field with the same field in the qualified record.
> > > If you only have to compare the item records then simply start the
> > > loop at that field. A simple MOD statement will tell you which of
> > > the detail items of the associated fields you are dealing with.
> >
> > "simple MOD statement" ?? Can you give us some more detail here?
> >
> > It sounds like there would be quite a bit more IO with this approach -
> > also, you mentioned that you would still need a loop... still if it is
> > simplier to code I would be interested in hearing the details.
>
> The ORIG(dummy) function would return the value of the field whose
> number is in the variable provided to it as it existed when the record
> first went into update mode after being positioned onto. Any changes
> after that would not affect the internal copy of the record used to
> provide the value for the ORIG() function, until the record pointer
> was changed. As a special feature, calling ORIG("0") would reset the
> internal array to the *current* version of the (possibly modified)
> record, should a programmer feel this was a good thing to do.
>
> Note that the indirection in the argument is critical, to permit it to
> be used in loops.
>
> Projected implementation time... oh, about a day.
>
> Expected impact on current codebase: None.
>
> :-)
>
> Cheers,
> -- jr 'happy to help' a
> --
> Jay R. Ashworth
> jra at baylink.com
> Designer                          Baylink
>     RFC 2100
> Ashworth & Associates        The Things I Think
>      '87 e24
> St Petersburg FL USA      http://baylink.pitas.com             +1
> 727 647 1274
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list