Uso un flag @debug o @test come variabile di input per tutti i proc stored complessi.
Quello che faccio con esso dipende quindi dal proc. Normalmente, emetto un rollback se in modalità test. Potrei anche mostrare i risultati di vari inserti prima del rollback per vedere se quello che mi aspettavo fosse quello che ho ottenuto.
Se ho SQL dinamico che quando uso @debug e in questo caso stampo lo sql invece di eseguirlo, così posso controllare l'istruzione SQL prodotta.
Naturalmente posso avere un @ test (usato solo quando sto influenzando i dati e voglio essere sicuro di poterlo ripristinare) e un @debug (per stampare l'SQl dinamico) nello stesso proc anche se di solito non lo faccio t eseguire in entrambe le modalità contemporaneamente.
Ho anche usato un @print per stampare i passaggi mentre vado se eseguo il debug (aiuta molto a vedere dove la cosa fallisce!) o in alternativa, puoi usare una variabile table per contenere i passaggi elaborati o qualsiasi codice di errore e quindi selezionare dalla variabile table dopo il rollback quando si è in modalità test per vedere cosa è realmente successo. È anche possibile inserire i valori dalla variabile table in una tabella permanente se è necessario vedere i dati nel tempo (lo facciamo per le importazioni complesse in modo da poter mostrare al client quanto spesso i loro dati di crappy hanno rotto l'importazione e ci hanno costretto a dover fare il lavoro per risolvere il problema). È importante utilizzare una variabile table e non una tabella temporanea perché ciò rimane nell'ambito dopo il rollback, una tabella temporanea viene ripristinata.
(Nota che la tabella delle variabili temporanee della tabella è specifica per SQL Server, non so se funzionerà con altri database.)
Un profiler può anche provvedere allo sql reale che è stato inviato al database e dovrebbe essere usato specialmente se non si stanno utilizzando proc memorizzati.