> Because user B doesn't know whether user A is changing the record or just
> looking at it. Both need a transaction open in order to view/modify the
> information. You can't close the transaction without closing the query

even

> if you're just looking at the data. If user A and B open a transaction and
> have the same record displayed, then user A changes something and posts

the

> changes and commits, user B is still viewing the record before the changes
> made by A. Then, when user B goes to change something and post, the record
> must be refreshed first before making the changes, right?
>

Sure, if you are displaying records. But I'm speaking in changes inside
triggers, after post the changes. When I do "update table set ..." then the
record is readed, isn't? Whell, if I'm right, if the record was locked by
another transaction, they would be waiting for a time before raise deadlock
error.

>
> There are no record locks in Interbase so you don't know that another user
> is updating it. In Paradox (ugh!) you can lock a record and test for that
> lock whenever someone else tries to access it, but that isn't the case in
> Interbase.
>

This can be resolved using try..except..end, intercepting deadlock error and
trying again. This is recomended by IB Guide. My question is: Why Interbase
dont't make this alone?

>
> I don't do these types of updates so I can't respond to it. My updates
> consist of data-aware controls responsible for posting the data through
> IBX's TIBDataset which has it's own update SQL command.
>
>

Ok.

>
> I would assume that the only way is to start the transaction just before
> executing the update query and committing it just after. You wouldn't want
> to do it this way if you have a transaction that's been open for a while
> already. You would want to commit any pending transactions, start a new

one,

> then execute the update, right? That would guarantee that you have the
> correct information for the update.
>

Yes.

Dufloth.