Modifying real fields in automatic (was Re: Some Sort ofControlFrom The Browse Screen)

[John Esak]

I can't believe I'm adding to this thread yet again... :-)  But this is
IMPORTANT.  Ken, I'm not disagreeing with you... But in one instance you are
wrong... Well, no, God, I would never say you are wrong.. :-)   Let's say
you stated something that is only true in certain instances and not
others... In fact actually not even in the majority of instances. I think it
needs clarification.

You said. 

> Well, to be fair, as I said earlier in this thread, the 
> modifying of a real 
> field in automatic is not going to cause data or index 
> corruption(*) because 
> filePro won't write the modified data!  But, the user will 
> still see(+) a 
> mismatch between what's on the screen and what's in the record.

And of course that is true. If just the AUTO runs, as if you are down
arrowing through the records in full screen mode, the value on the screen
will change, but filePro does not store the modified data. Obvious, and
clear.  But, in my example, just putting 

     then: 1 = 1 + "1"

On the AUTO table without any WRITE, will certainly change the data if you
press "u".  The AUTO table runs first, changes the data... Then you are in
the INPUT table... When you press SAVE, you *store* the value the way the
AUTO table has just modified it.  I know it doesn't apply so much in
George's code, but in most AUTO tables this would be true... Plus, even more
insidious, if you merely run a report as I suggested, the same true, actual
modification of the field occurs.  The AUTO table changes it and the -z
table stores it that way.  

Now, I'm only saying this to clarify your statement above, because some
people would get the wrong idea.  I have spent hours writing articles and
making movies of the FLOW of filePro through each table and different type
of processing, and to just say the AUTO table won't truly modify the data
isn't really right.... Don't you agree?  Well not right, the correct thing
to say, is it is a too simplistic description of how things can and can't
happen when it comes to the AUTO table.

Hence, your dedication (and mine) and nearly everyone else's to just NEVER
put assignments to real fields in the AUTO table is reasonable, and indeed
actually good and correct programming technique.   George says he is also on
this team... So we are all settled, eh?

John
.







> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of Kenneth Brody
> Sent: Sunday, October 24, 2010 1:12 PM
> To: flowersoft at compuserve.com
> Cc: filepro-list at lists.celestial.com
> Subject: Re: Modifying real fields in automatic (was Re: Some 
> Sort ofControlFrom The Browse Screen)
> 
> On 10/23/2010 12:02 AM, flowersoft at compuserve.com wrote:
> [...]
> >> Oh, and as for only people using the -y myauto changing 
> the value... What
> > do
> >> you think I meant?  Two people using normal processing?  
> :-)  I meant
> >> everyone involved using your processing, do you want to 
> state which person
> >> will see the correct value or not in that case? That is 
> the only scenario
> >> that matters in this discussion, no?
> >
> > You got me there. I must admit that during those 15 minutes 
> I did not
> > anticipate that two or more individuals might be checking 
> off the items that
> > have cleared from the same checking account at the same time.
> > However, if that were to be the case, my code would still 
> work because the
> > tree doesn't really fall unless the user presses "U". :-)
> 
> Well, to be fair, as I said earlier in this thread, the 
> modifying of a real 
> field in automatic is not going to cause data or index 
> corruption(*) because 
> filePro won't write the modified data!  But, the user will 
> still see(+) a 
> mismatch between what's on the screen and what's in the record.
> 
> However, given that you don't even care about the modified 
> value, and you're 
> only doing it "just in case" the user has pressed 'U', why 
> don't you put it 
> in input processing where it belongs?
> 
> 
> (*)  Assuming you don't then have processing that, for 
> example, uses the 
> modified value and stores it someplace else, like a lookup file.
> 
> (+)  Unless you make sure to never let the user know about 
> the mismatch.
> 
> -- 
> Kenneth Brody
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list