> >> I realize that I should fix my applications so that deadlocks don't
> >> occur at all. Unfortunately, the occurence of deadlocks is so
> extremely
> >> rare that I really have no hope of finding the cause. So instead I
> am
> >> looking for a way to fix the effects. I know that a Backup/Restore
> >> cycle removes my deadlocks. But - is there an alternative way that
> would not
> >> require an exclusive access to the database?
> >
> > deadlocks are not a phenomenon which is corrected only via B/R cycle.
> You
> > only have to commit the transaction.
> > If you read up a little on transaction isolation you may quickly twig
> to
> > what your issue is. You could change your isolation e.g. ...
> > deadlocks are your friend not your enemy - learn to detect them and
> use
> > them, don't avoid them
>
> To put things into perspective: Among all of my installations I see one
> or perhaps two occurences of deadlock per year. The bug is hidden in
> some 200 thousand lines of code that I would need to go through. I
> agree
> that it would be great to find and fix the uncommitted transaction, but
> the costs of doing so are too high.
>
> Pepak

how can it be hidden? A debugger will stop on that exception right on that
line of code. Which will expose the transaction being used for the edit in
question. Even 500 thousand or a million lines of code is trivial in this
context. What language, IDE, degugger are you using?
Alan