为什么SQL2008调试器不会进入某个子存储过程

时间:2010-05-21 20:59:21

标签: sql-server-2008 stored-procedures temp-tables

我遇到了T-SQL与SQL2008(对比SQL2000)的差异,这些差异导致我走向死胡同。我已经验证了在创建#TEMP的调用者和引用它的子sProc之间共享#TEMP表的技术在SQL2008 See recent SO question中仍然有效。

我的核心问题仍然是一个关键的“子”存储过程在SQL2000中正常工作但在SQL2008中失败(即子sProc中的FROM子句被编码为:SELECT * FROM #AREAS A)尽管#AREAS由呼叫父母。而不是现在发布代码片段,这是另一个可能有助于你提出建议的症状。

我在SQL Mgmt Studio中启动了新的调试器:

EXEC dbo.AMS1 @S1='06',@C1='037',@StartDate='01/01/2008',@EndDate='07/31/2008',@Type=1,@ACReq = 1,@Output = 0,@NumofLines = 30,@SourceTable = 'P',@LoanPurposeCatg='P'

这是一个非常大的sProc,奇怪的关键代码如下:

create table #Areas
(   
  State     char(2)             
, County    char(3)             
, ZipCode   char(5)         NULL                
, CityName  varchar(28)     NULL
, PData     varchar(3)      NULL
, RData     varchar(3)      NULL
, SMSA_CD   varchar(10)     NULL
, TypeCounty    varchar(50) 
, StateAbbr char(2) 
)
EXECUTE dbo.AMS_I_GetAreasV5        -- this child populates #Areas
  @SMSA = @SMSA 
, @S1 = @S1     
, @C1 = @C1     
, @Z1 = @Z1     
, @SourceTable = @SourceTable
, @CustomID = @CustomID 
, @UserName = @UserName 
, @CityName = @CityName 
, @Debug=0
EXECUTE dbo.AMS_I_GetAreas_FixAC   -- this child cannot reference #Areas (in 2008 only!)
  @StartDate = @StartDate      -- secondarily, I cannot STEP INTO this sProc 
, @EndDate = @EndDate
, @SMSA_CD = @SMSA_CD   
, @S1 = @S1
, @C1 = @C1
, @Z1 = @Z1
, @CityName = @CityName 
, @CustomID = @CustomID
, @Debug=0
-- continuation of the parent sProc**

我可以单步执行父存储过程。当我到达上面的第一个子sproc时,我可以STEP INTO dbo.AMS_I_GetAreasV5或STEP OVER执行。当我到达第二个孩子sProc的调用 - dbo.AMS_I_GetAreas_FixAC - 我尝试进入它(因为这是问题陈述的地方)并且忽略了STEP INTO(即改为像STEP OVER一样;但我知道我按下了F11不是F10)。但它执行了,因为当在EXECUTE之后将控制权返回给语句时,我单击Continue继续执行,结果窗口显示dbo.AMS_I_GetAreas_FixAC(即第二个子)存储过程中的错误。

有没有办法“预加载”sProc,目的是在其条目上设置断点,以便我可以在其中执行?

总之,我想知道是否无法进入给定的子sproc可能与此特定子项无法引用其父(调用者)创建的#temp相关。

1 个答案:

答案 0 :(得分:0)

我发现其中一个被叫存储过程(即孩子们)显然有

SET NOCOUNT OFF

一些长期被遗忘的原因。

显然,SQL 2008中的事物行为在生效时会有很大不同。

我最终在所有sProcs中识别出上述所有行,将它们更改为

SET NOCOUNT ON

..而且,我在实例级别检查了NOCOUNT。这解决了这些非常奇怪的问题。