Re: Preventing deadlocks
From: David Gugick (davidg-nospam_at_imceda.com)
Date: 12/07/04
- Next message: jxstern: "Re: dbcc inputbuffer and long commands"
- Previous message: Brandon Slezak: "RE: Locking and Transactions /w Linked Servers"
- In reply to: Maury Markowitz: "Re: Preventing deadlocks"
- Next in thread: Maury Markowitz: "Re: Preventing deadlocks"
- Reply: Maury Markowitz: "Re: Preventing deadlocks"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 7 Dec 2004 14:16:37 -0500
Maury Markowitz wrote:
> "David Gugick" wrote:
>> A deadlock does not kill a connection. It only raises an error.
>
> That's the problem. The deadlock is occuring because one application
> died out on the network and is holding its query open. Then when
> someone else issues the same query, it gets stuck. At least I think
> that's what's happening.
>
That's a blocking issue, not a deadlocking issue as you now know. SQL
Server will eventually release those locks, but it can take some time
until it clears up the connection. Why is the application dying in the
first place?
There is a lock timeout and query timeout that you should be able to set
from your Access code. The lock timeout determines how long a process
will wait on a locked resource before the query is automatically
cancelled. I believe you'll still need to issue a rollback if that
happens.
I don't know enough about Access to help more than that.
-- David Gugick Imceda Software www.imceda.com
- Next message: jxstern: "Re: dbcc inputbuffer and long commands"
- Previous message: Brandon Slezak: "RE: Locking and Transactions /w Linked Servers"
- In reply to: Maury Markowitz: "Re: Preventing deadlocks"
- Next in thread: Maury Markowitz: "Re: Preventing deadlocks"
- Reply: Maury Markowitz: "Re: Preventing deadlocks"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|