Mark,

---- big snip
>
>I agree with the example that very definitely I have a user revising a customer record. Only that record is locked. INSERT-SQL only lock the file header and does not try to place a like on the table. *Append and Append From* lock the table; *Append Blank, Append From Array and Insert-SQL* only lock the header. This is the important distinction between those 5 options to add records. Users can continue to modify records without preventing operations requiring only a table header lock. That's why, IMHO, INSERT-SQL and APPEND FROM ARRAY are the best ways of adding records to a table. To minimize a deadly embrace, I have a second table (record id generator) that I lock and keep locked until AFTER I have inserted rows into a table. This guarantees only 1 user at a time can insert rows.
>
>The only thing that kills all our good programming is a rogue application accessing our data at the same time. All we can do is plan and develop as good of an error-trap as possible.
>
>On that note -- Once we think we have idiot-proofed something, someone builds a better idiot.
---- end snippage

*IF* I could be more knowledgeable about locking a header versus locking a record, I might be able to agree with you.

REGARDLESS, though, my major point to you is: Yours is a logical and comfortable method, but WHY INVITE POSSIBLE DISASTER? We know we *can* run into trouble with two locks going on sequentially but AT THE SAME TIME. Many "key" files are a single record, so there may not be a lot of difference between locking only the header (I know INSERT is not used in that case) and locking the file (which it is in this case, being a single record).

I simply feel that keeping the possibility of a deadly embrace "at bay" as much as possible is the safest way to go. Yes, I'm basically a chicken programmer.

Cheers,
Jim N