Mark,

>
>i disagree. if table.dbf remains locked durint the insert-sql then no other user can lock table.dbf and therefore can not procede on to the insert-sql step. to me this is better solution -- do not unlock table.dbf until after insert-sql. this will assure only 1 insert-sql can occur at any one time and response times should be acceptable.

The above is a very good theory, but in my humble opinion is begging for a deadly embrace situation *somewhere*.
Here's how my theory goes. . .
You cannot have a deadly embrace when you are updating only ONE table.
Since it takes updating at least two tables (update required because that's where locks come in) to get a deadly embrace, then *IF* all updates occur in the SAME SEQUENCE (as per your 'theory' above), then there is also no possibility of a deadly embrace.
However, all that is needed to change that situation for *ALL* participants is one rogue application where the sequence is not maintained. Let's face it, THIS IS A VERY LIKELY SCENARIO in any application set (it will likely not be the case that an app always updates a specific set of tables in a specific sequence.

So, the only "safe" way to code things is, when possible, to lock/update/unlock a single table at a time.

Cheers,
Jim N