Sql server 2005 子存储过程无法引用在父存储过程中创建的本地临时表

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

在SQL2008测试中，我发现了两种不同行为的表现形式。首先，在设计时，新的“intellisense”功能在Management Studio的子存储过程编辑中抱怨#TEMP是一个“无效的对象名”。但更糟糕的是，在执行时，调用的父存储过程在嵌套的子存储过程中失败

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

这似乎是一个过于激进的建议，无论是从查找所有问题点的工作量，还是从web应用程序调用这些存储过程时可能/可能产生的恶劣影响（即多用户问题）来看

---

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

在存储过程之间共享临时表是一个很好的功能：，我很惊讶它不适合您。也许你应该尝试一个非常简单的例子，看看这是否有效。然后，如果这是可行的，开始寻找其他原因

在management studio的查询窗口中尝试以下操作：

创建以下两个过程：

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)

---

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

多谢各位。这一定是更微妙的事情。我将更深入地了解真正的麻烦制造者。