1

在我们的生产 SQL2000 实例上，我们有一个包含数百个存储过程的数据库，其中许多使用在代码中“早期”创建#TEMP 表的技术，然后各种内部存储过程由该父 sProc 执行。在 SQL2000 中，内部或“子”sProc 插入到#TEMP 或从#TEMP 中选择数据没有问题。简而言之，我假设他们都可以引用这个#TEMP，因为他们使用相同的连接。

在使用 SQL2008 进行测试时，我发现了两种不同行为的表现形式。首先，在设计时，新的“智能感知”功能在子 sProc 的 Management Studio EDIT 中抱怨 #TEMP 是“无效的对象名称”。但更糟糕的是，在执行时，调用的父 sProc 在嵌套的子 sProc 内失败。

有人建议解决方案是更改为##TEMP，这显然是一个全局临时表，可以从不同的连接中引用。

从追踪所有问题点的工作量以及从 Web 应用程序调用这些 sProcs（即多用户问题）时可能/可能的不良影响来看，这似乎过于激烈。

这确实是 SQL2005 或 SQL2008 关于#TEMP（本地临时表）的行为变化吗？我们跳过了 2005 年，但我想更准确地了解为什么会发生这种情况，然后再开始尝试破解所需的修复程序。谢谢。

4

2 回答 2

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)
于 2010-05-21T18:05:40.513 回答
1

我们现在（在 2000、2005 和 2008 年）完全按照您的描述执行此操作，而无需将本地临时表更改为全局临时表。

于 2010-05-21T18:07:24.173 回答