Record locking

[John Esak]

>
> As drives and computers get faster, timing problems are bound to happen
> especially with windows based systems.
>
> Richard Kreiss
> GCC Consulting
>

Okay, I am not trying to be argumentative... (we can talk more in the FP
Room of course) but, I have heard people say this before... and it just does
not make sense. Other than age-old CPU-speed related code (which, does not
get written anymore by anyone with any kind of a brain) the above statement
does not make sense. As computers get faster and hard disks get faster and
etc., things will only get better. This can _not_ cause problems...
certainly not with any filePro code not working properly because of the
extra speed. So, I guess I just flatly disagree with these kinds of
suggestions.  In other words, regarding programming code, there is (or
should never be) any such thing as "timing problems".  In fact, I don't know
what "timing problems" means in the way you're using it.  As I said in
another note, filePro is using in-memory copies of every value. If your code
increments a value, that is the value which will be used.  It does not
matter that you may have asked that value to be written to a real field out
on the disk. I fyou have properly locked the record... no other filePro
process can read that record and grab an earlier value.... earlier than the
value which you are going to leave in that field when you write and unlock
the record.  In other words, timing has _nothing_ to do with it.

So when people talk about even more strange things like write caching of one
kind or another and faster networks and etc.... it all makes no difference
if the record is locked properly and filePro certain does _its_ part of the
job in this regard.  Otherwise, we all need to see such misbehaving code.
As you say, your problem is most likely outside of filePro.

John