On Jan 18, 2008 11:42 AM, Helen Borrie <helebor@...> wrote:
> At 12:05 AM 19/01/2008, you wrote:
> >> >How can I avoid this error?
> >> >
> >> >lock conflict on no wait transaction
> >> >deadlock
> >> >update conflicts with concurrent update
> >>
> >> Can you explain why you want to avoid this error?
> >
> >Shouldn't we avoid errors in our applications? :)
>
> No, not if they are not "errors". A locking conflict is an EXCEPTION. It results from a conflict between two attempts to update the same record. We CATCH exceptions in our application and act accordingly.
>
> >Actually, it wasn't clear for me what would cause such error. Now I
> >know it's a long transaction locking a lot of records.
>
> Well, it *could* be a long transaction or a short transaction. It's not the length of the transaction that causes the locking conflict. It is the fact that the database engine is DESIGNED to prevent one transaction from updating a record if another user already has a pending update (or a delete) on that record. You (application developer) are meant to catch that particular locking conflict in the error status vector, interpret its implications and handle it. Typically, you would intercept that exception and give the user a message such as "Someone else is changing that record. Please try again."
>
> Behind the scenes, at the client, you would have some mechanism whereby you save the user's changes somewhere, rollback the transaction and start over using the saved changes, so that the user simply has to click a button. There are several alternative ways you might want to handle that exception, as well...
>
>
> ./heLen
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>



--
Erick Sasse