[x]
Posted via EE Mobile

Search, ask, and monitor your questions on the go with EE Mobile. Visit Experts Exchange from your mobile device and never be out of touch again.

Question
[x]
Attachment Details
[x]
The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

  • The Grade of the Solution
  • The Zone Rank of the Expert Providing the Solution
  • The Number of Author and Expert Comments
  • The Number of Experts Contributing
  • The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

10.0

Dropping a temp table that is not my own, or killing its owner process (AKA getting the SPID of the temp table's owner process)

Asked by jimbobmcgee in MS SQL Server

Tags: SQL Server 2000, tempdb

We have a SQL Server 2000 legacy app that has a proc that utilises a #table.  That temp table has a named PK constraint which specifies the fill factor.  If the proc is run twice at the same time, an 'object exists'-type error is raised against the PK constraint.

I need a foolproof way to ensure this proc always runs and I figured I could either: specify the fill factor in an unnamed PK; or drop the named PK if it exists.  I don't think I can do the former and the latter is giving me grief.

I can get the OBJECT_ID of the temp table and the PK  If both are not NULL, I know the table is mine and can just drop it.  If the table ID is NULL, I know I have a problem.

I can't change the existing fixed table structure and I can't use normal tables or ##tables because the two concurrent processes can't write into the same table.  I can't bail the 2nd process if the 1st one exists because the cursed business logic suggests that the 2nd process must assume the 1st has bailed.   My only option, I feel, is to try and kill the 1st process.

So I need to get the SPID of the #table owner (from its OWNER_ID) and KILL it.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
IF OBJECT_ID('tempdb..tmpPK_account') IS NOT NULL 
	AND OBJECT_ID('tempdb..#deal_account') IS NOT NULL BEGIN
	-- i own the table so drop it
	DROP TABLE #deal_account
END
 
IF OBJECT_ID('tempdb..tmpPK_account') IS NOT NULL 
	AND OBJECT_ID('tempdb..#deal_account') IS NULL BEGIN
	-- i do not own the table so kill the owner
	
	-- this is the temp table object info
	SELECT * FROM tempdb..sysobjects WHERE id = (
		SELECT parent_obj 
		FROM tempdb..sysobjects 
		WHERE id = OBJECT_ID('tempdb..tmpPK_account')
	)
 
	DECLARE @spid INT, @kill VARCHAR(32)
 
	-- ...FILL IN THE BLANKS...
 
	SET @kill = 'KILL ' + CAST(@spid AS VARCHAR)
	EXEC (@kill)
END
 
-- ...later on...
CREATE TABLE [#Deal_Account] 
(
	[PARENT_ROLE] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[ROLE] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[ACCOUNT] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[DEAL] [varchar] (252) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[DEAL_LINE] [varchar] (252) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[id] [int] IDENTITY (0, 1) NOT NULL,
	CONSTRAINT [tmpPK_account] PRIMARY KEY NONCLUSTERED ([id]) 
		WITH FILLFACTOR = 90 
		ON [PRIMARY] 
)
[+][-]02/09/09 12:57 PM, ID: 23594404Accepted Solution

View this solution now by starting your 30-day free trial. Setting up your free trial is quick, easy, and secure. We will return you to this solution, unlocked, when you're done.

About this solution

Zone: MS SQL Server
Tags: SQL Server 2000, tempdb
Sign Up Now!
Solution Provided By: angelIII
Participating Experts: 2
Solution Grade: A
 
[+][-]02/09/09 01:09 PM, ID: 23594527Assisted Solution

Assisted solutions are selected by the member who asked the question as a comment that contributed to their question's solution.

Start your 30-day free trial to view this Assisted Solution or ask the Experts your question.

 
[+][-]02/10/09 02:57 AM, ID: 23599073Author Comment

Often, when Experts are collaborating with members who have asked questions, they will request additional information about the problem. Askers respond with an author comment like this one.

Start your 30-day free trial to view this Author Comment or ask the Experts your question.

 
 
Loading Advertisement...
20091021-EE-VQP-81 - Hierarchy / EE_QW_3_20080625