Home Forums SQL Server 2008 SQL Server Newbies trying to KILL a SPID, getting 'Cannot use KILL to kill your own process.' RE: trying to KILL a SPID, getting 'Cannot use KILL to kill your own process.'

  • polkadot (10/13/2013)


    I think restarting SQL Server should have reset the numbers for SPID 54.

    It did. No connections or connection-related information survives a restart.

    Clearly, there is some spid hanging and the only one in the sp_who2 report for Sandbox is SPID 54. All the other SPIDS are for the other databases in my instance, like master, msdb, and others.

    There's no indication from anything you've said that there's anything hanging anywhere. The restart would have terminated all running connections and if there was still something else running the sp_who would have shown it.

    I just tried to delete Sandbox db, BUT, SQL Server won't let me.

    Probably the session that you're currently running all those sp_who and kill from is using that DB, or another object explorer connection.

    Something, and if it isn't SPID 54 I don't know how to find out what is, is preventing me from *even deleting* the db. I get error:

    "Cannot drop database "Sandbox" because it is currently in use."

    What database context are you running the DROP DATABASE from? If you're currently using the Sandbox DB yourself (the database drop down in the menu reads Sandbox, then the connection that you're currently using is using that DB and preventing it from being dropped.

    Disconnect object explorer, run USE master, make sure all your other query windows are closed then drop the DB. You cannot drop a database that you are using, even if the only connection using it is the one running the DROP.

    What to do. I am now ready to delete the db and I thought that was pretty broad stroke to fix problem. Perhaps tossing the laptop wouldn't be a solution either:w00t:. Any other suggestions pl-easse?

    You mean other than suggesting you don't actually have a problem?

    There's nothing wrong with your databases from what you've said. Nothing unusual, nothing sgtrange.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass