Qual è il tuo metodo preferito per il debug delle stored procedure di MS SQL?

Question

La maggior parte dei miei SP può essere semplicemente eseguita (e testata) con i dati inseriti manualmente. Funziona bene e l'utilizzo di semplici istruzioni PRINT mi consente di eseguire il "debug".

Ci sono tuttavia casi in cui è coinvolta più di una procedura memorizzata e trovare dati validi da inserire è noioso. È più semplice attivare le cose direttamente dalla mia app web.

Ho una piccola esperienza con il profiler ma non ho trovato un modo per esplorare cosa sta succedendo una volta per linea nelle mie stored procedure.

Quali sono i tuoi metodi?

Grazie, come sempre.

Nota: sto assumendo uso di SQL Server 2005 +

Answer 1

Profiler è molto utile, basta aggiungere SP: StmtStarting eventi e filtrare l'attività verso il basso solo il processo impostando SPID = xxx. Una volta installato, è un gioco da ragazzi vedere cosa sta succedendo.

Answer 2

Si può effettivamente collegare un debugger al server sql :) - da vs, dato che avete configurato che sul server SQL.

Controllare questo collegamento per ulteriori informazioni, notare che è possibile impostare i punti di interruzione :) https://web.archive.org/web/20090303135325/http://dbazine.com/sql/sql-articles/cook1.

controllare questo link per un insieme più generale di informazioni: http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx

Aggiornamento: Per quanto riguarda "Ci sono tuttavia casi in cui più di una stored procedure è coinvolto e trovare dati validi all'ingresso è noioso E 'più facile. solo per attivare le cose dall'interno della mia app Web. "

Suggerisco di impostare test di integrazione, incentrati sui metodi specifici che interagiscono con tali procedure. Se le procedure sono guidate dall'app Web, è un ottimo posto per test + input validi che puoi eseguire in qualsiasi momento. Se ci sono più app che interagiscono con le procedure, guarderei invece le unità testando le procedure.

Answer 3

Preferisco utilizzare solo stored proc per il reperimento del set di dati e qualsiasi "lavoro" complesso sul lato dell'applicazione. Dato che sei corretto, provare a eseguire il "debug" di ciò che sta accadendo all'interno del budo di un processo memorizzato nidificato a più livelli, con il cursore, con la tabella temporanea, è molto difficile.

Detto questo, MS KB 316549 descrive come utilizzare Visual Studio per eseguire il debug di stored procedure.

Secondo questo articolo, ci sono una serie di limitazioni per il debug in questo modo:

• Non si può "rompere" l'esecuzione.
• Non è possibile "modificare e continuare".
• Non è possibile modificare l'ordine di esecuzione della dichiarazione.
• Sebbene sia possibile modificare il valore delle variabili, le modifiche potrebbero non avere effetto perché i valori delle variabili sono memorizzati nella cache.
• L'output dall'istruzione SQL PRINT non viene visualizzato.

Edit: Ovviamente, se si sei la persona che fa questo proc memorizzato, quindi non ce la fanno "molti più livelli, il cursore-looping, temp-tabella utilizzando, e nidificati".Nel mio ruolo di DBA, però, è più o meno quello che incontro quotidianamente dagli sviluppatori di app.

Answer 4

Per non sapere quali sarebbero gli input validi, è necessario testare una vasta gamma di ingressi, inclusi in particolare ingressi non validi. Dovresti definire i casi di test prima di scrivere i tuoi proc. Quindi hai una serie di test riproducibili da eseguire ogni volta che qualcuno cambia il processo complesso.

Answer 5

Il mio team utilizza SP per regola come interfaccia con il database; lo facciamo in modo tale che l'utente dell'applicazione possa eseguire ESCLUSIVAMENTE SP (con la nostra convenzione di denominazione).

Una best practice che utilizziamo, che funziona bene, è che alcuni script di test sono contenuti nei commenti SP e devono essere eseguiti a ogni rev di un SP o allo sviluppo di un nuovo SP.

Si dovrebbe sempre, SEMPRE testare l'SP nel modo più completo possibile senza che sia coinvolto alcun livello di applicazione (tramite Management Studio, ad esempio).

Answer 6

Questo trucco è abbastanza a portata di mano:

Custom user configurable Profiler Events

Answer 7

Assicurarsi che passo in principale proc memorizzato in VS2005/2008, quando incontra una funzione annidata, ha colpito F11 (passo verso) per entrare in .. .continue debugging ... Non era molto ovvio dal menu di debug.

Answer 8

Preferisco non eseguire il debug, ma piuttosto lo sviluppo di test driven, che elimina quasi la necessità di eseguire il debug.