October 28, 2008 at 4:03 pm
That would be the best bet - but, if you don't find anything it is time to call the vendor. I have a feeling that regardless of what you find - you are going to have to call the vendor anyways to get the lock cleared.
Most vendors frown on their clients modifying the database outside of their application. You need to make sure that is okay before you make any changes.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
October 28, 2008 at 7:42 pm
Michael Earl (10/27/2008)
When a user disconnects, all SQL Server locks are released. You cannot have a resource locked without the associated spid. So, if you have users that are not actually connected to the database and the application is indicating they have records locked, the application must be using it's own locking mechanism rather than the internal SQL record locking.This is one of the bigger problems with most "I can do it better" home-grown locking mechanisms. They tend to leave garbage uncollected when a session terminates incorrectly.
I would take this issue back to the vendor.
Agreed. The vendor needs to see this.
I will mention that Distributed Transactions can get ghosted for extended periods if the two-phase commit fails for some reason. If the spid in question is -2 investigate killing a process by Unit Of Work on BOL.
Craig Outcalt
November 3, 2008 at 11:26 am
It was a vendor issue, they had files on the application server that has transactions written to it, those files needed to be deleted after removing all connections to the application and to the SQL server.
The application rebuilt the files after it was restarted.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply