---snip---

>My comment:
>You must write "interesting" apps if this is not a very likely scenario in your designs! Let us take, for example, a simple case of a "customer master" table (and let us not worry too much about the "design" of the table in this case):
>I (but seemilgly not you) would have a routine which CREATES a new Customer Master record. It might go to some table to get the next (key) Customer number to be assigned, update that record to indicate the number has been taken, and update that file. Then I would write the actual Customer Master record with the key which I had gotten from the 'next key' table.
>BUT there would sometimes be a need to REVISE data in a Customer Master record - say the customer's address changes, or his/her phone number or some tally of "service interactions" needs to be updated. SUCH THINGS would be done in a separate routine, possibly even (probably) routineS, which would UPDATE the Customer Master record and, probably, some other record somewhere (perhaps a "log" or some "history" or some other such thing.
>
>SO, *I* content that it IS COMMON and LIKELY that the same file will be updated from several different routines within an app, probably in combination with other different files.
>
---snip---

Jim:

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.