> If you want to protect successive commits from overwriting newly

committed work, either

> (1) use pessimistic locking or
> (2) set RecVersion to False and LockWait to True (not necessarily

what you want, as the second update will succeed eventually) or leave
LockWait false and handle deadlocks, or

> (3) change to tiConcurrency isolation and handle deadlocks.
>

Solution (3) is not good, since it prompts for the lock error, but I
can't see the other person changes with a fast refresh, but I've to
end/restart the transaction.
I've tried (2) with AutoCommit to false and with LockWait to false.
Now program A posts the changes and then program B prompts for an
error in posting it's changes (lock conflict). But if I've to
close/reopen dataset in program B before program A posts the changes,
the same error of lock occurs! So program B is "locked" even it does
not want to do editing anymore (I'm editing the first row of the
dataset, inside a grid). So bad.
Moreover the problem is that I've AutoCommit to true, and having so
the B program can post it's data even if A program has changed it.
Must I manually perform a refresh before editing? No IBO automation?
;) What about accounting program where data integrity is paramount?
Having pessimistic locks or tiConcurrency seems not very good for
Interbase, as I've read.
What about many people entering invoices and having to reduce unsold
stock of goods? A reads 10, B reads 10, A reduces it to 9 and posts
it, B reduces it to 9 and posts it. So you have 9 instead of 8!
BTW, is there a way IBO re-reads rows from the database when scrolling
in the IB_Grid?
Thanks for your really prompt help!
Marco Menardi