Hi,

At October 7, 2004, 23:46, John Hart wrote:

> I wrote a maintenance program, started it twice and edited the same row. The
> first update changed the row, the second update did not raise an exception
> and therefore overwrote the first changes. I added a breakpoint on the
> except' code to prove it was not called.

The first step is to understand the architecture of Firebird and
Interbase (I mention both since I don't know which one you are using).
They both use a multi-generational architecture(MGA). This type of
architecture doesn't block 2 users from editing the same row at the
same time, unless some transaction settings are in place. For more
information about MGA and what it means, you can look here:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;PAGES;NAME='ibp_bill_todd_mga'

> ----------

> The properties of TIBODatabase are set to

> DefaultTransaction.AutoCommit = true
> DefaultTransaction.Isolation = tiCommitted
> DefaultTransaction.LockWait = false
> DefaultTransaction.RecVersion = True
> DefaultTransaction.ServerAutoCommit = False

> The properties of TIBOQuery are set to

> CommitAction = caInvalidateCursor ( I tried caRefresh)
> PessimisticLocking = false
> ReadOnly = false
> RecordLive = true

> I have tried all combinations of the above and have spent over 20 hours on this problem.

Actually, it's not a problem, but just requiring basic understanding
how Interbase and Firebird transactions isolations and settings work.

> I have tried PessimisticLocking and LockWait = true and it works as expected.

If you are looking for record locking, then yes you will need
PessimisticLocking and LockWait. But, also keep the transactions as
short as possible.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)