>You can't - it's intentionally the nature of the beast. Remember, all

updates are row-level so,

> if you have the "parent" of a FK relationship tied up in an

uncommitted update, the INSERT

> is disallowed, in case the change to the parent record alters the PK.

Understood. The PK won't be changed but I guess firebird can't know
that. I guess changing the FK to not cascade wouldn't help since it's
still a check constraint?

> To avoid the long delays, don't use WAIT as the lock resolution

setting for transactions in

> which these inserts are performed. Instead, let the exception be

thrown, intercept it and ask

> the user to try again later. (Or, if you know how, queue the data and

implement a retry loop.)



I took a middle road and set a lock timeout. I think I'll pass on the
retry loop because that could make things more asynchronous than I'm
comfortable with for this particular case.

>>Is it possible to find out what transaction/statement is blocking this
>>one?
>No. It wouldn't help, anyway, since you don't know who owns the

transactions. And, if you

>need to have master table accesses causing bottlenecks like this, make

sure you don't allow

>applications to hold on to uncommitted work on these master tables for

long periods.



Well if I knew what statement was causing the lock I could check if I
forgot to close a transaction there. There's only a limited amount of
procedures that update the Loads table however, so I guess I can
optimize each of them.



Thank you very much for your assistance.



Mathias



[Non-text portions of this message have been removed]