|Subject||Re: [ib-support] Deadlock and wait|
|Author||Marcos Vinicius Dufloth|
> Because user B doesn't know whether user A is changing the record or justeven
> 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
> if you're just looking at the data. If user A and B open a transaction andthe
> have the same record displayed, then user A changes something and posts
> changes and commits, user B is still viewing the record before the changesSure, if you are displaying records. But I'm speaking in changes inside
> made by A. Then, when user B goes to change something and post, the record
> must be refreshed first before making the changes, right?
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
>This can be resolved using try..except..end, intercepting deadlock error and
> 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
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.
> 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
> then execute the update, right? That would guarantee that you have theYes.
> correct information for the update.