>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.

This is Michel's case, so there's no deadly embrace here. How can you have a deadly embrace when all it's about the table that keeps the IDs and the table in which the insert is done? I just don't see it.

>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.

This is not at all a VERY LIKELY SCENARIO in any app. At least, not if the app is well designed and developed.

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

This is good if it's possible. But is NOT AT ALL THE ONLY SAFE WAY.

Vlad