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

[Jay R. Ashworth]

On Mon, Mar 17, 2008 at 07:02:24PM -0700, Jeff Harrison wrote:
> 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.

Got it.  In this case, of course, since the fields were poked in by a
batch process, we *know* that they "really" contain the data we wanted.

On a related topic, is there now (or has there ever been :-) a
*reliable* way to figure out *which* of those 3 passes of automatic
processing is being run?

(On reflection, it's actually *2* passes: the last one is in the same
context as the first: "INTOVIEW" as opposed to the second one which is
"INTOEDIT".  And yes, Scobey, I'm looking at you.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274

	     Those who cast the vote decide nothing.
	     Those who count the vote decide everything.
	       -- (Joseph Stalin)