0

我似乎遇到了临时表垃圾收集的问题：

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，并且效果很好。现在，使用临时表，它不会......我愿意接受有关替代方法的建议。

4

2 回答 2

6

当存储过程超出范围时，#temp 表将被删除（嗯，延迟删除）。因此，它在存储过程范围之外对您不可用。为了在过程完成后查看#temp 的内容，您需要在执行存储过程之前创建它，并将其填充到内部......或在存储过程中执行选择。

对于更新的需求，为什么不直接使用带有 UserID 键的永久表，并更新存储过程以将 UserID 作为参数？如果您已经有一个用户表，您肯定可以将更新的会话信息存储在一两列中。不需要 CONTEXT_INFO 或 #temp 表废话。

于 2012-06-25T21:36:48.447 回答
0

我为这个问题找到了一个解决方案，但我自己认为它不可靠。这是关于有两个不同的连接字符串：

  1. 首先使用主数据库连接字符串设置主数据库的上下文信息
  2. 其次是您的正常应用程序的连接字符串。
于 2012-07-30T13:52:26.290 回答