Je rencontre des différences dans T-SQL avec SQL2008 (vs SQL2000) qui me conduisent à des impasses. J'ai vérifié que la technique de partage de tables #TEMP entre un appelant qui CRÉE le #TEMP et l'enfant sProc qui le référence reste valide dans SQL2008 See recent SO question. Mon problème principal reste une procédure stockée "enfant" critique qui fonctionne correctement dans SQL2000 mais qui échoue dans SQL2008 (une clause FROM dans l'enfant sProc est codée comme: SELECT * FROM #AREAS A) malgré la création de #AREAS par le parent appelant. Plutôt que de poster des extraits du code maintenant, voici un autre symptôme qui peut vous aider à suggérer quelque chose.Pourquoi le débogueur SQL2008 n'entrait PAS dans une certaine procédure stockée enfant
Je tirai le nouveau débogueur dans 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'
Ceci est un très grand SProc et l'extrait de code clé qui est bizarre est la suivante:
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**
je peux parcourir l'exécution de la procédure stockée parente. Quand j'arrive au sproc du premier enfant, je peux soit entrer dans dbo.AMS_I_GetAreasV5, soit l'ignorer. Quand j'arrive à l'invocation du second enfant sProc-dbo.AMS_I_GetAreas_FixAC - j'essaie d'y entrer (parce que c'est là où se trouve l'énoncé du problème) et STEP INTO est ignoré (c'est-à-dire traité comme STEP OVER à la place; F11 pas F10). Il a été exécuté cependant parce que lorsque le contrôle est retourné à l'instruction après l'EXECUTE, je clique sur Continuer pour terminer l'exécution et les fenêtres de résultats montrent les erreurs dans la procédure stockée dbo.AMS_I_GetAreas_FixAC (c'est-à-dire le 2ème enfant).
Existe-t-il un moyen de "pré-charger" un sProc dans le but de définir un point d'arrêt sur son entrée afin que je puisse poursuivre l'exécution à l'intérieur? En résumé, je me demande si l'impossibilité d'entrer dans un sproc enfant donné peut être liée à la même incapacité de cet enfant particulier à référencer un #temp créé par son parent (appelant).