1

在我們的生產SQL2000實例上,我們有一個包含數百個存儲過程的數據庫,其中許多存儲過程使用在代碼中「早」創建#TEMP表的技術然後通過這個父sProc獲取EXECUTEd的各種內部存儲過程。在SQL2000中,內部或「子」sProc在插入#TEMP或從#TEMP中選擇數據時沒有問題。總之,我認爲他們都可以參考這個#TEMP,因爲他們使用相同的連接。子sProc無法引用在父sProc中創建的本地臨時表

在使用SQL2008進行測試時,我發現了2種不同行爲的表現形式。首先,在設計時,新的「智能感知」功能在兒童sProc的Management Studio EDIT中抱怨#TEMP是「無效的對象名稱」。但更糟糕的是,在執行時,被調用的父sProc在嵌套的子sProc內失敗。

有人建議解決方案是改爲## TEMP,這顯然是一個可以從不同連接引用的全局臨時表。

這似乎過於激烈的建議,從工作量來追逐所有問題點以及從Web應用程序(即多用戶問題)調用這些sProcs時可能/可能令人討厭的影響。

這確實是SQL2005或SQL2008中有關#TEMP(本地臨時表)的行爲變化嗎?我們跳過了2005年,但我想更準確地瞭解爲什麼在我離開之前發生這種情況並嘗試修補所需的修復程序。謝謝。

回答

2

在存儲過程之間共享臨時表是一個很好用的功能:http://www.sommarskog.se/share_data.html#temptables,我很驚訝它不適合你。也許你應該嘗試一個非常簡單的例子,看看它是否會起作用。那麼如果這項工作開始尋找其他原因。

嘗試這從一個查詢窗口管理工作室:

創建這兩個過程:

CREATE PROCEDURE called_procedure 
(@par1 int, @par2 char(5)) 
AS 
INSERT INTO #tmp VALUES (@par1,@par2) 
GO 

CREATE PROCEDURE caller 
AS 

CREATE TABLE #tmp (col1 int  NOT NULL 
        ,col2 char(5) NULL 
       ) 
EXEC called_procedure 1, 'AAA' 
EXEC called_procedure 2, 'BBB' 

SELECT * FROM #tmp 
GO 

然後運行它們:

exec caller 

這是我得到的SQL Server 2005上:

col1  col2 
----------- ----- 
1   AAA 
2   BBB 

(2 row(s) affected) 
1

我們現在(2000年,2005年和2008年)按照您的描述完成此工作,而無需更改本地到全球臨時表。

+0

謝謝。這一定是更微妙的東西。我會更深入地看待實際的麻煩製造者。 – 2010-05-21 18:12:15

相關問題