Wanneer we gedwongen worden om dynamische sql te gebruiken in een opgeslagen proces, doen we het volgende. voeg een invoervariabele van debug toe die een bitveld is. Als het 0 is, wordt het exec-statement verwerkt als het 1 is, dan krijg je in plaats daarvan een print-statement. Ik stel voor dat je iets soortgelijks doet om te debuggen. Druk in plaats van uit te voeren de resultaten van uw SQL af of voeg eventueel de SQL toe aan een tabel, aangezien het in een lus lijkt te gebeuren. Dan kun je de sql bekijken die is gebouwd en zien waar het fout is gegaan.
Declare debug bit
set debug = 1
...
if debug = 1 Begin Print @SQL End
Else
Begin Exec (@sql) End
Alternatief
Maak een tabel met de naam mydynamiccode_logging (met een sql-kolom van dezelfde lengte als de max sql-instructie, een rundatecolumn en alle andere kolommen die u nodig zou kunnen vinden (ik zou rekening houden met de invoervariabelen die zijn gebruikt om de sql-instructie te vormen, de gebruiker, de toepassing als meer dan één dit stuk code gebruikt)
Voordat u het exec-statement uitvoert, voert u iets als volgt uit:
insert mydynamiccode_logging (sql, rundate)
values (@sql, getdate())
Nu zou je ook het debug-bitveld kunnen toevoegen en alleen loggen als je het hebt veranderd in debug-modus of je zou altijd kunnen loggen, afhankelijk van het systeem en hoeveel extra tijd dit kost om te doen en hoe dicht de rest van het systeem is. U wilt de prod niet aanzienlijk vertragen door te loggen.