Почему отладчик SQL2008 НЕ будет входить в определенную дочернюю хранимую процедуру - PullRequest
0 голосов
/ 22 мая 2010

Я сталкиваюсь с различиями в T-SQL с SQL2008 (по сравнению с SQL2000), которые ведут меня в тупик. Я проверил, что техника совместного использования таблиц #TEMP между вызывающей стороной, создающей #TEMP, и дочерним sProc, который ссылается на нее, остается действительной в SQL2008 См. Недавний вопрос SO .

Моя основная проблема остается критической «дочерней» хранимой процедурой, которая прекрасно работает в SQL2000, но не работает в SQL2008 (т. Е. Предложение FROM в дочернем sProc кодируется как: 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**

Я могу пошагово выполнить родительскую хранимую процедуру. Когда я доберусь до первого дочернего элемента выше, я могу либо STEP INTO dbo.AMS_I_GetAreasV5, либо STEP OVER его выполнения. Когда я прихожу к вызову 2-го дочернего элемента sProc - dbo.AMS_I_GetAreas_FixAC - я пытаюсь STEP INTO (потому что именно в этом и заключается постановка задачи), а STEP INTO игнорируется (т.е. обрабатывается как STEP OVER вместо этого; но я ЗНАЮ, что я нажал F11 не F10). Однако он был выполнен, потому что когда элемент управления возвращается в оператор после EXECUTE, я нажимаю кнопку «Продолжить», чтобы завершить выполнение, и в окне результатов отображаются ошибки в хранимой процедуре dbo.AMS_I_GetAreas_FixAC (то есть 2-го дочернего элемента).

Есть ли способ «предварительной загрузки» sProc с целью установки точки останова на его входе, чтобы я мог продолжить выполнение внутри него?

В целом, мне интересно, может ли неспособность войти в данный дочерний элемент sproc быть связанной с той же неспособностью этого конкретного дочернего элемента ссылаться на #temp, созданный его родителем (вызывающей стороной).

1 Ответ

0 голосов
/ 10 июня 2010

Я обнаружил, что одна из вызванных хранимых процедур (то есть дети), по-видимому, имела

SET NOCOUNT OFF

по какой-то давно забытой причине.

Очевидно, что поведение вещей в SQL 2008 совсем другое, когда это действует.

В итоге я идентифицировал все строки, как указано выше, во всех sProcs, изменив их на

SET NOCOUNT ON

.. а также я проверил NOCOUNT на уровне экземпляра. Это исправило эти очень странные проблемы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...