At 12:38 AM 10-08-02 +0200, you wrote:

>Hi!
>
>What would be the proposed way, to set up a behaviour like this:
>
>1. Read one row into memory (select * from table)
>2. manipulate it in memory (takes a long time, so I don't want to have
>in within transaction)
>3. if row has the same version number as before: write new data back to
>table (update table set ...)
> else croak
>
>I guess it can be done with a special setup of transaction isolation
>level and pessimistic locking.

No, not if you separate the data from a transaction context. The record
version is a server side thing so, if you fetch your data set and then
commit the transaction, the transaction context is lost. A pessimistic
lock is no good in this situation, since it will disappear when you commit
the transaction.

>Currently I often run into deadlock errors.

Deadlock errors are OK!! They indicate that another transaction has
changes pending on one or more rows that are affected by your transaction's
changes.

If it's important for user A to know that user B is working on the same
record, then use pessimistic locking to *prevent* user B from starting an
edit operation on that record. The way this works is that, when user B
tries to get the pessimistic lock (by doing the same dummy update that has
been performed by user A), it will get a lock conflict error. IBO won't
let user B go into Edit mode unless user B can acquire the pess. lock
itself. All you need to do is intercept the lock conflict error and send
user B a message like "This record is busy - try again later".


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com