At 12:57 PM 11-07-01 +0000, you wrote:

>I'm a little ashamed of asking about that, but I thought things should
>behave one way, while it's going other way, so there must be something
>I've missed and I can't figure out what.
>I've a program running in two PC, or, put, two instances of the
>program running against the same database (for debug purpose, of
>course).
>The connection has a default transaction trBase with transaction
>isolation to tiCommitted and autocommit to true.

tiCommitted is the READ COMMITTED isolation. With RecVersion True, it is designed to work just as you described - transactions ignore pending updates by others.

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.

If your environment has a high level of diferent users accessing the same rows, the settings you have are not ideal. I'd go with option 1 if transactions are going to be quickly committed. Otherwise, maybe review your workflow and find out why different users are able to step on one another's toes.

Cheers,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________