> > i have yet got the long -awaite deadlock
> > locking the record via IB_SQL and
> > posting a new record from the test application
> >
> > Now i have a new one question :
> >
> > Setting LockWait = true the deadlock error is raised only when the
> > lock condition is removed

> Are you sure?

I'm sure !!! i tried it
i know it's strange but that's what's happen

>I'm not talking from my own experience here, but my
> understanding is that if LockWait is true, the transaction just waits
> until the lock has been removed (no matter how long it takes), and
> then does whatever it has to do. So you'll only set LockWait to true
> if you're pretty sure that any locks will be quickly removed (like in
> the now famous example).

i thought like you

> If an error is raised, I guess it can't be a lock error (unless
> there's some built-in timeout)

i get a deadlock error :(

what do you mean with built-in timeout ?
Do you mean any value in TIB_Transaction.TimeOutProps ?

could be this built-in timeout raising the
deadlock after removing the lock condition ?

> If LockWait is false and there is a lock, am error will be raised
> immediately. You can then have your code retry after some time... or
> not... or ask the user...

> > is it correct to intercept the deadlock and handle it
> > in the TIB_Queery.OnPostError ?

> I suppose so, since the conflict will arise upon posting.

> > what's the best solution to intercept the deadlock
> > and try to post again ?

> If - like in the example - you know that locks will only exist for a
> limited time, the simplest thing seems setting LockWait to true.

i thought so, but i had to write some code in TIB_Queery.OnPostError
because the deadlock error raise after removing the lock condition

Any help would be appreciate

Thanks in advance,
Stefano Campri

> Greetings,
> Paul Vinkenoog