Debug di Stored Procedure, trigger e funzioni in SQL Server 2008

Una delle novità più significative di SQL Server 2008 per i database developer è la possibilità di effettuare il debug di Stored Procedure, trigger e funzioni all'interno del programma SQL Server Management Studio.

Non si tratta di una vera e propria innovazione, perché uno strumento di debug era già presente nel Query Analizer di SQL Server 2000. Questo strumento, tuttavia, fu eliminato da SQL Server 2005, che richiedeva l'utilizzo di Visual Studio per effettuare il debug delle proprie routine. Nei casi in cui questa strada non fosse percorribile (soprattutto per la necessità di acquistare una licenza aggiuntiva di Visual Studio), si doveva ricorrere a soluzioni "manuali", come inserire istruzioni PRINT all'interno del codice, per mostrare il valore delle variabili utilizzate e per tenere traccia del flusso di esecuzione.

L'approccio manuale, come è facile intuire, ha il grande svantaggio di richiedere uno sforzo in più, essendo difficilmente automatizzabile, dal momento che il database developer deve, di volta in volta, preoccuparsi di inserire a mano le istruzioni PRINT nei punti giusti del codice; d'altra parte, non potendo seguire il flusso delle istruzioni passo-passo, in molti casi questo era l'unico modo per determinare, ad esempio, il punto esatto e le variabili coinvolte nel fallimento di una procedura.

Accogliendo le richieste degli amministratori di basi di dati e, soprattutto, dei database developer, il debug di stored procedure, trigger e funzioni è stato reintrodotto nell'ultima versione del DBMS di Microsoft. È supportato in tutte le edizioni di SQL Server 2008, compresa la versione Express, ma solo se il database a cui ci si connette è realizzato con queste release; non è quindi possibile sfruttare il nuovo Management Studio per utilizzare il debugger con le versioni precedenti del DBMS.

Attivare il supporto al debugger

Il debugger Transact-SQL può essere utilizzato immediatamente, senza necessità di alcuna configurazione aggiuntiva, se l'SQL Server Management Studio è in esecuzione sullo stesso computer dell'istanza del DBMS. Quando, invece, il Management Studio viene lanciato da una postazione diversa da quella che ospita il Database Engine, è necessario attivare in entrambi i computer alcune eccezioni relative a programmi e porte tramite l'applicazione Windows Firewall del Pannello di controllo.

Nel computer che esegue l'istanza di SQL Server a cui ci si vuole connettere, si deve configurare Windows Firewall nel modo seguente:

• Aggiungere la porta TCP 135 all'elenco delle eccezioni
• Aggiungere il programma sqlservr.exe all'elenco delle eccezioni

Per impostazione predefinita, sqlserver.exe viene installato nel percorso

C:ProgrammiMicrosoft SQL ServerMSSQL10.NomeIstanzaMSSQLBin

dove NomeIstanza è MSSQLSERVER per l'istanza predefinita e il nome dell'istanza per qualsiasi istanza denominata.

Se i criteri di dominio richiedono che le comunicazioni di rete siano eseguite tramite IPsec, è necessario aggiungere anche la porta UDP 4500 e la porta UDP 500 all'elenco delle eccezioni.

Nel sistema da cui si vuole avviare il debugger tramite SQL Server Management Studio, Windows Firewall deve essere impostato come segue:

• Aggiungere la porta TCP 135 all'elenco delle eccezioni
• Aggiungere il programma ssms.exe (SQL Server Management Studio) all'elenco delle eccezioni

Il file ssms.exe viene generalmente installato nel percorso

C:ProgrammiMicrosoft SQL Server100ToolsBinnVSShellCommon7IDE

Per eseguire il debug, inoltre, è necessario utilizzare un utente che faccia parte del ruolo sysadmin.

Il debugger di SQL Server 2008 in azione

Il debugger di SQL Server 2008 consente di eseguire stored procedure, trigger e funzioni in modalità passo passo, visualizzare i valori delle variabili utilizzate e modificare la sequenza delle istruzioni, in modo da poter seguire il flusso di esecuzione e verificare che tutto funzioni come previsto. Per avviarlo, basta inserire, all'interno delle proprie routine, un punto di interruzione in corrispondenza della riga desiderata, quindi premere il pulsante Debug sulla barra degli strumenti:

Figura 1. Il pulsante di avvio del debug

Vediamo più in dettaglio come utilizzare questo strumento. Iniziamo creando un semplice database di prova, utilizzando lo script Create.sql in allegato, in modo da definire il seguente schema:

Figura 2. Lo schema del database di prova

Ora creiamo una stored procedure per recuperare l'elenco degli utenti: vogliamo che, se viene specificato il nome di una città, essi siano filtrati in base al suo valore; in caso contrario, devono essere restituiti tutti i contatti presenti nella tabella Users:

CREATE PROCEDURE [dbo].[GetUsers]
  @cityName NVARCHAR(50) = NULL
AS
BEGIN
  IF @cityName IS NULL
    SELECT u.Name, u.[Address], c.Name
    FROM Users u INNER JOIN Cities c ON u.IDCity = c.IDCity
  ELSE
    SELECT u.Name, u.[Address], c.Name
    FROM Users u INNER JOIN Cities c ON u.IDCity = c.IDCity
    WHERE c.Name = @cityName
END

Innanzi tutto, verifichiamo il suo funzionamento eseguendo le seguenti istruzioni EXEC:

EXEC GetUsers               -- Restituisce tutti i contatti
EXEC GetUsers 'Paperopoli'  -- Restituisce i contatti di Paperopoli

A questo punto possiamo provare le funzionalità di debug di SQL Server 2008. Clicchiamo nello spazio a fianco delle istruzioni, in corrispondenza della prima EXEC, in modo da definire un punto di interruzione:

Figura 3. Impostare un breakpoint

Per avviare il debug, premiamo il pulsante Debug che abbiamo mostrato in precedenza o, in alternativa, usiamo la combinazione di tasti ALT+F5: così facendo, SQL Server Management Studio entrerà in modalità debugging. L'esecuzione si interromperà in corrispondenza della prima istruzione, aspettando una nostra azione. Premiamo il pulsante F11 per entrare nel codice della stored procedure GetUsers:

Figura 4. Il debugger in esecuzione

In questa immagine possiamo notare la barra degli strumenti Debug, contenente i di pulsanti per controllare il flusso di esecuzione, e una serie di finestre utili per l'analisi del codice, tra cui:

Locals

mostra automaticamente l'elenco delle variabili definite nel blocco di codice corrispondente (nel nostro esempio, @cityName);

Watch 1

permette di aggiungere nuovi variabili o espressioni di cui si vuole controllare il valore

Call Stack

mostra l'elenco delle funzioni e dei metodi che sono stati richiamati durante l'esecuzione (dal più recente al più vecchio)

Breakpoints

contiene la lista di tutti i punti di interruzione definiti nel codice

I comandi del debugger

Sono disponibili diversi comandi per gestire la sessione di debug, associati ai comodissimi tasti funzione:

Step Into (F11)

elabora la prossima istruzione del flusso e apre una nuova finestra dell'editor di query nella modalità di debug se tale comando esegue una stored procedure, un trigger o una funzione (abbiamo utilizzato questa modalità poco fa, per entrare nel corpo della procedura richiamata dall'istruzione EXEC)

Step Over (F10)

ha un funzionamento simile a quello di Step Into, eccetto per il fatto che con questo comando non viene eseguito il debug di funzioni, stored procedure o trigger richiamati da altre routine. Nel nostro esempio, premendo il tasto F10 in corrispondenza del punto di interruzione, verrebbe eseguita l'intera procedura GetUsers (richiamata dal primo EXEC), e l'esecuzione si interromperebbe in corrispondenza di EXEC GetUsers 'Paperopoli'

Step Out (SHIFT+F11)

consente di eseguire il codice restante di un trigger, una funzione o una stored procedure ignorando i punti di interruzione definiti in questi oggetti; la normale modalità di debug riprende quando il controllo viene restituito al codice che ha chiamato il modulo

Infine, per eseguire il codice fino al prossimo punto di interruzione (oppure fino al termine, se non sono stati impostati altri breakpoint), si deve usare la combinazione ALT+F5. Tutti questi comando sono disponibili anche nella barra degli strumenti e nel menu Debug del Management Studio.

Abbiamo detto che all'inizio che, durante il debug, è possibile anche modificare il valore delle variabili. Nell'esempio che stiamo eseguendo, la variabile @cityName ha valore NULL: facciamo clic nella colonna Value corrispondente all'interno della finestra Locals (Fig. 4) e scriviamo Topolinia, quindi confermiamo con INVIO. Ora premiamo F10, in modo che il debugger valuti l'istruzione IF @cityName IS NULL (su cui è in attesa): sebbene l'argomento passato alla stored procedure sia NULL, noi ne abbiamo modificato il valore, quindi l'esecuzione si sposterà nel ramo ELSE; con un'altra pressione del tasto F10 verrà mostrato il risultato della SELECT, ovvero, come ci aspettiamo, tutti i contatti della città Topolinia, e l'esecuzione si sposterà sulla seconda EXEC. Concludiamo il debug premendo ALT+F5, in modo da eseguire il comando, senza entrare nuovamente nella stored procedure.

Naturalmente, le stesse modalità di debug sono disponibili anche nel caso in cui si stia lavorando con una funzione o un trigger.

Conclusioni

In questo articolo abbiamo illustrato le principali caratteristiche del debugger integrato nel SQL Server Management Studio di SQL Server 2008, uno strumento che colma una delle maggiori lacune della precedente versione del DBMS. Esso risulta spesso indispensabile per verificare il corretto funzionamento del proprio codice e per individuare gli errori che sono stati commessi, ad esempio, nella scrittura di una Stored Procedure. Per approfondire l'argomento, è utile consultare anche la sezione Utilizzo del debugger Transact-SQL su MSDN.