Robby wrote:

>...snip...
>(My full reason for needing any kind of locking is described in the
>thread at http://groups.yahoo.com/group/firebird-
>support/message/44643 . Alexandre was kind enough to get me on the
>right track, but I need some claification on just this one more
>thing.)
>
>

...snip...

>Anyhow, where this gets a bit confusing for me is that I've read the
>paper on Auditable Series over at IBObjects, and they use a simple
>dummy update kind of method to get a lock on the appropiate data
>until the transaction ends. They say that this will prevent other
>transactions from accessing the data (a "planned deadlock" as they
>call it). BUT, from what I've read from the article at
>http://www.linuxjournal.com/article.php?sid=7010 ...they say the
>same sort of operation will cause the other transaction to get an
>older copy of that data (citing the multi-version concurrency system
>in FB). Which is it? Does this matter on the properties of the
>transaction that I start? With SET TRANSACTION, I only saw that NO
>WAIT would cause the transaction to error out when it found a lock
>on the data...nothing about getting an older version of the data...
>
>
>
>

...snip...

>Thanks,
>
>Robby
>
>

Robby,

Another link for you ;-)
http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;KNOWLEDGEBASE;ID='377'

the docs will be better than just try to solve your problem, with the
links I expect you I understand better the diferences...

Just to sumarize:
The most important part for you is:
-- Start paste from above link --

1. READ COMMITTED = This means that a transaction can see and update all
committed records in the database. Read committed has two further options that
can be specified. They are :
RECORD_VERSION, and NO RECORD_VERSION.
RECORD_VERSION = Reads the latest committed version of a record.
It will ignore uncommitted, but more recent versions of a record.
NO RECORD_VERSION = Reads only the latest version of a record.
If the latest version of the record is uncommitted and WAIT lock resolution is
being used, the transaction waits until the this version is resolved
(committed or rolled back). If NO WAIT lock resolution is used then an error is
reported immediately.

2. SNAPSHOT
This isolation level allows the transaction to see a view of the records as
they were when the transaction began. Subsequent changes by other transactions
that occur after the transaction began will not be seen.

3. SNAPSHOT TABLE STABILITY
Prevents other transactions from modifying rows in use by the transaction.
Other transactions are allowed to view the rows in use by the transaction.

-- End paste from above link --



see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br