Possibly SOLVED Re: Now *here's* an odd problem with dclerk

[Jeff Harrison]

--- "Jay R. Ashworth" <jra at baylink.com> wrote:

> On Mon, Mar 17, 2008 at 04:05:02PM -0700, Jeff
> Harrison wrote:
> > No problem.  You probably simply have a "44=
> > [something]" in the auto table.  Not a
> reccommended
> > practice - This is not filepro's fault - the
> > programmer should know better.
> 
> Sure, but what *is* the result of making an
> assignment to a real field
> in auto these days?  Version defined?  Undefined?
> 
> And why would this interact with the selections, but
> not with indices?
> 
> Enquiring minds wanna know.
> 
> Cheers,
> -- jra
> -- 

The result of making an assignment to a real field is
consistent, and has been as far back as I can recall. 
Remember that filepro will only write to the record
automatically when it is at the end of the update
mode.  In IUA for example when you bring up a record,
filepro runs the auto processing, but no write occurs
so the field will "appear" to have a different value
than what is actually stored.  When you press "U" to
update, auto processing runs again, and when you press
"SAVE" input processing runs, the information is
actually written, and then auto processing runs again.

Both selections and indexes will respect the values
that are actually stored in the fields - not what
"appears" to be stored.

Jeff Harrison
jeffaharrison at yahoo.com

Author of JHImport and JHExport. The fastest and
easiest ways to import and export with filepro. 


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs