Modifying real fields in automatic (was Re: Some Sort of Control From The Browse Screen)

[Kenneth Brody]

On 10/17/2010 7:06 PM, John Esak wrote:
> No, you showed 5="Y" or something like that on AUTOMATIC... That is a no-no.
> It's writing a real field on the AUTOMATIC table. No, there isn't a WRITE
> command, but you are still modifying the record in AUTO... And that's
> baaaaaaad.  Please let's not go into it again as to why.... Suffice to say,
> it's bad because the record is not locked and if two people or more are
> browsing with this kind of coding, you are going to get unreliable stuff in
> the indexes, and well, it's just plain bad programming. But, I'm sure you
> know that.  Don't know why you suggest it a lot, but that's your thing. I
> just mention the bad effects to play devil's advocate and explain to
> unitiates that changing values of real fields on the AUTO table...
> Especially of indexed fields is not a good idea.  You and anyone else is
> welcome to do it, however.
[...]

Actually, if you're not in update mode, then modifying real fields in 
automatic won't cause index problems, nor will there be a clash with more 
than one person viewing the record at the same time, because the changed 
data won't be written to the record.  You'll see one value on the screen, 
but the record actually contains a different value.  We've gotten numerous 
"bug reports" over the years complaining that the browse mode was "broken" 
because it was showing a different value than they saw while viewing the 
screen.  In reality, the browse mode was "correct" because it was showing 
the value that was in the record, whereas the screen was showing a value 
that was modified by automatic, but not actually in the record.

So, the code that was posted here which toggled the value of field 5 if you 
are on screen 9 would cause the user to see the exact wrong value when 
viewing the record via screen 9.  (ie: if the field were blank, you would 
see "Y", and if the field had "Y", you would see blank.)

-- 
Kenneth Brody