LOOKUP+WRITE (was Re: Slow issue with filepro on Windows 2003 / XP clients)

[Boaz Bezborodko]

Kenneth Brody wrote:
> On 1/7/2010 5:02 PM, Boaz Bezborodko wrote:
> [...]
>> I experienced the "deleted key" error on a program I was developing a
>> few days ago.  I'm not sure I remember exactly what was the problem, but
>> I remember that it had something to do with WRITEing the data (WRTIE
>> <file>) to that file and then looking to add something else to it and
>> WRITEing again.  In between I was testing to see if the file was open
>> (IF:<file>) before the next WRITE operation.  In between something else
>> was able to delete the record because it was no longer locked and the
>> result was the "Deleted key" error.  The answer was to either re-protect
>> the record with another lookup or completely closing the lookup file
>> after the WRITE and re-opening with another lookup.  Either way I had to
>> protect the record from a deletion from elsewhere in the system.
>
> What you describe (modifying the record after you WRITE it) is 
> basically the same thing as modifying an unprotected lookup.
>
>> Using WRITE has the problem of keeping a lookup file open in the
>> existing users' table while removing the protection for the record to
>> other users.  So a test of "IF:<file>" or "IF: not<file>" will still
>> show "TRUE" for a file even if no record is open on it.
>
> I see no problem here.  The lookup record is still available for 
> reading after you WRITE it.  The lookup did succeed, and the record is 
> still there for you to read, which is why "if lookupname" returns true.
>
> [...]
>
I meant "problem" as meaning something that you have to concern yourself 
with because you've changed the nature of the lookup.  You now have the 
record available for writing, but it is no longer locked.  Therefore, 
you have to take such a situation into consideration.

bozob