När vi tvingas använda dynamisk sql i en lagrad proc, gör vi följande. lägg till en indatavariabel för debug som är ett bitfält. Om det är 0, kommer exec-satsen att behandla om den är 1, då får du en print-sats istället. Jag föreslår att du gör något liknande felsökning. Istället för att köra, skriv ut resultaten av din SQL eller infoga eventuellt SQL i en tabell eftersom det verkar ske i en loop. Sedan kan du titta över sql som byggdes och se var det gick fel.
Declare debug bit
set debug = 1
...
if debug = 1 Begin Print @SQL End
Else
Begin Exec (@sql) End
Alternativt
Skapa en tabell som heter mydynamiccode_logging (med en sql-kolumn med samma längd som max sql-satsen, en rundatecolumn och alla andra kolumner du kan tycka är nödvändiga (jag skulle överväga indatavariablerna som används för att skapa sql-satsen, användaren, applikationen om fler än en använder denna kodbit)
Innan du kör exec-satsen kör något så här:
insert mydynamiccode_logging (sql, rundate)
values (@sql, getdate())
Nu kan du också lägga till felsökningsbitfältet och bara logga när du har ändrat det till felsökningsläge eller så kan du alltid logga, beror på systemet och hur mycket extra tid detta tar att göra och hur slam resten av systemet är. Du vill inte bromsa proden avsevärt genom att logga.