Når vi tvinges til at bruge dynamisk sql i en lagret proc, gør vi følgende. tilføje en inputvariabel for debug, som er et bitfelt. Hvis det er 0, vil exec-erklæringen behandle, hvis det er 1, så får du en print-erklæring i stedet for. Jeg foreslår, at du gør noget, der ligner fejlretning. I stedet for at udføre, udskriv resultaterne af din SQL eller indsæt eventuelt SQL i en tabel, da det ser ud til at ske i en løkke. Så kan du se over den sql, der blev bygget, og se, hvor det gik galt.
Declare debug bit
set debug = 1
...
if debug = 1 Begin Print @SQL End
Else
Begin Exec (@sql) End
Alternativt
Opret en tabel kaldet mydynamiccode_logging (med en sql-kolonne af samme længde som max sql-sætningen, en rundatecolumn og hvilke andre kolonner du måtte finde nødvendige (jeg ville overveje inputvariablerne, der bruges til at lave sql-sætningen, brugeren, applikationen hvis mere end én bruger dette stykke kode)
Før du kører exec-statmentet, kør noget som dette:
insert mydynamiccode_logging (sql, rundate)
values (@sql, getdate())
Nu kan du også tilføje debug-bit-feltet og kun logge, når du har ændret det til debug-tilstand, eller du kan altid logge, afhænger af systemet og hvor meget ekstra tid det tager at gøre, og hvor smækket resten af systemet er. Du ønsker ikke at bremse prod-hastigheden væsentligt ved at logge.