臨時表垃圾收集

我似乎遇到了與臨時表垃圾收集問題：臨時表垃圾收集

CREATE PROCEDURE dbo.SetTestTempTable(@value bit) 
AS 
SET NOCOUNT ON 
IF OBJECT_ID('tempdb..#TestTempTable') IS NOT NULL 
    DROP TABLE #TestTempTable 
SELECT @value AS Value INTO #TestTempTable 

GO 

EXEC dbo.SetTestTempTable 1 
SELECT * FROM #TestTempTable

上面的代碼產生錯誤

Msg 208, Level 16, State 0, Line 3 
Invalid object name '#TestTempTable'.

我想是因爲#TestTempTable是越來越垃圾回收當proc退出時。

有沒有辦法來防止這種情況？我不希望每個調用者都需要在調用過程之前顯式創建臨時表。

更新：我爲什麼要這樣做？

我需要存儲一些上下文信息（基本上是一個會話變量）。我爲此使用了CONTEXT_INFO。 SQL Azure不支持CONTEXT_INFO，所以我正在重構。從本質上講，我有一個函數：

GetMySessionVariableName（）

和程序

SetMySessionVariableName（值）

此前，這一功能和過程中使用CONTEXT_INFO內部，並且工作得很好。現在，使用臨時表，它不......我接受關於替代方法的建議。

來源

2012-06-25 Jeff

就目前來看，這是不可能的，因爲你的最終約束。您可以選擇臨時表，然後從臨時表中進行選擇。我們都會同意這一點，因爲您可能剛剛選擇了數據，這會非常愚蠢。因此，導致下一部分，*這顯然不是整個圖片*。如果你能提供更多的信息，那麼幫助會更好。 – swasheck

@ p.campbell他將如何查詢存儲過程之外的表變量？ –

增加了更多的上下文 – Jeff

當存儲過程超出範圍時，#temp表將被刪除（以及延遲刪除）。所以它不在存儲過程的範圍之內。爲了在過程完成後查看#temp的內容，您需要在執行存儲過程之前創建它，並將其填充到內部或在存儲過程中執行選擇。

對於更新的需求，爲什麼不使用帶有UserID上的鍵的永久表，並更新存儲過程以將UserID作爲參數？如果你已經有了一個用戶表，那麼你肯定可以將更新的會話信息存儲在一列或兩列。不需要CONTEXT_INFO或#temp表廢話。

來源

2012-06-25 21:36:48

有一個解決方案，我發現這個問題，但我自己並不認爲這是可靠的。這是關於有兩種不同的連接字符串：

首先與主數據庫連接字符串
二是你的正常應用程序的連接字符串中設置主數據庫的上下文信息。

來源

2012-07-30 13:52:26

臨時表垃圾收集

回答

相關問題