Debugging delle stored procedure (C#)

di Scott Mitchell

Scaricare il PDF

Le edizioni di Visual Studio Professional e Team System consentono di impostare punti di interruzione e passare alle stored procedure all'interno di SQL Server, semplificando il debug delle stored procedure come il debug del codice dell'applicazione. Questa esercitazione illustra il debug diretto del database e il debug delle stored procedure all'interno delle applicazioni.

Introduzione

Visual Studio offre un'esperienza di debug completa. Con alcune sequenze di tasti o clic del mouse, è possibile usare punti di interruzione per interrompere l'esecuzione di un programma ed esaminare il relativo stato e flusso di controllo. Oltre a eseguire il debug del codice dell'applicazione, Visual Studio offre supporto per il debug delle stored procedure dall'interno di SQL Server. Proprio come i punti di interruzione possono essere impostati all'interno del codice di una classe code-behind ASP.NET o di una classe di livello di logica di business, così possono essere inseriti anche all'interno delle stored procedure.

In questa esercitazione verrà esaminata l'esecuzione di stored procedure da Esplora server in Visual Studio e come impostare i punti di interruzione che vengono raggiunti quando viene chiamata la stored procedure dall'applicazione ASP.NET in esecuzione.

Annotazioni

Sfortunatamente, le stored procedure possono essere inserite e sottoposte a debug solo tramite le versioni Professional e Team Systems di Visual Studio. Se si usa Visual Web Developer o la versione standard di Visual Studio, è possibile leggere i passaggi necessari per eseguire il debug delle stored procedure, ma non sarà possibile replicare questi passaggi nel computer.

Concetti relativi al debug di SQL Server

Microsoft SQL Server 2005 è stato progettato per fornire l'integrazione con Common Language Runtime (CLR), ovvero il runtime usato da tutti gli assembly .NET. Di conseguenza, SQL Server 2005 supporta oggetti di database gestiti. Ciò significa che è possibile creare oggetti di database come stored procedure e funzioni di User-Defined (UDF) come metodi in una classe C#. Ciò consente a queste stored procedure e funzioni definite dall'utente di usare le funzionalità in .NET Framework e dalle proprie classi personalizzate. Naturalmente, SQL Server 2005 fornisce anche il supporto per gli oggetti di database T-SQL.

SQL Server 2005 offre supporto per il debug sia per gli oggetti di database T-SQL che per gli oggetti di database gestiti. Tuttavia, questi oggetti possono essere sottoposti a debug solo tramite le edizioni di Visual Studio 2005 Professional e Team Systems. In questa esercitazione verrà esaminato il debug di oggetti di database T-SQL. L'esercitazione successiva esamina il debug di oggetti di database gestiti.

Il post del blog Panoramica del debug di T-SQL e CLR in SQL Server 2005 del team di integrazione di SQL Server 2005 CLR evidenzia i tre modi per eseguire il debug degli oggetti di SQL Server 2005 da Visual Studio:

• Debugging diretto del database (DDD) - da Esplora Server possiamo entrare in qualsiasi oggetto di database T-SQL, come stored procedure e funzioni definite dall'utente (UDF). Esamineremo DDD nel passaggio 1.
• Debug dell'applicazione : è possibile impostare punti di interruzione all'interno di un oggetto di database e quindi eseguire l'applicazione ASP.NET. Quando viene eseguito l'oggetto di database, il punto di interruzione verrà raggiunto e il controllo passerà al debugger. Si noti che con il debug dell'applicazione non è possibile entrare in un oggetto di database partendo dal codice dell'applicazione. È necessario impostare esplicitamente i punti di interruzione nelle stored procedure o nelle funzioni definite dall'utente in cui si desidera che il debugger si fermi. Il debug dell'applicazione viene esaminato a partire dal passaggio 2.
• Il debug da un progetto DI SQL Server - Visual Studio Professional e Team Systems edition includono un tipo di progetto DI SQL Server comunemente usato per creare oggetti di database gestiti. Nell'esercitazione successiva verranno esaminati i progetti di SQL Server e ne verrà eseguito il debug.

Visual Studio può eseguire il debug di stored procedure in istanze di SQL Server locali e remote. Un'istanza di SQL Server locale è quella installata nello stesso computer di Visual Studio. Se il database di SQL Server in uso non si trova nel computer di sviluppo, viene considerato un'istanza remota. Per queste esercitazioni si usano istanze di SQL Server locali. Il debug di stored procedure in un'istanza remota di SQL Server richiede più passaggi di configurazione rispetto al debug di stored procedure in un'istanza locale.

Se si usa un'istanza di SQL Server locale, è possibile iniziare con il passaggio 1 ed eseguire questa esercitazione fino alla fine. Se si usa un'istanza remota di SQL Server, tuttavia, è prima necessario assicurarsi che quando si esegue il debug si è connessi al computer di sviluppo con un account utente di Windows con un account di accesso di SQL Server nell'istanza remota. Inoltre, sia questo account di accesso al database che l'account di accesso del database usato per connettersi al database dall'applicazione ASP.NET in esecuzione devono essere membri del sysadmin ruolo. Vedere la sezione Debug di oggetti di database T-SQL in istanze remote alla fine di questa esercitazione per altre informazioni sulla configurazione di Visual Studio e SQL Server per eseguire il debug di un'istanza remota.

Infine, comprendere che il supporto del debug per gli oggetti di database T-SQL non è altrettanto ricco di funzionalità come il supporto del debug per le applicazioni .NET. Ad esempio, le condizioni e i filtri dei punti di interruzione non sono supportati, sono disponibili solo un subset delle finestre di debug, non è possibile usare Modifica e continuazione, la finestra Immediata viene resa inutile e così via. Per altre informazioni, vedere Limitazioni per i comandi e le funzionalità del debugger .

Passaggio 1: Entrare direttamente in una stored procedure

Visual Studio semplifica il debug diretto di un oggetto di database. Esaminiamo come usare la funzionalità di debug diretto del database (DDD) per entrare nel dettaglio della Products_SelectByCategoryID procedura archiviata nel database Northwind. Come suggerisce il nome, Products_SelectByCategoryID restituisce informazioni sul prodotto per una determinata categoria; è stato creato nell'esercitazione Uso di stored procedure esistenti per i TableAdapters del DataSet tipizzato. Per iniziare, passare a Esplora server ed espandere il nodo del database Northwind. Quindi, approfondire nella cartella Stored procedure, fare clic con il pulsante destro del mouse sulla stored procedure Products_SelectByCategoryID e scegliere l'opzione Esegui in stored procedure dal menu di scelta rapida. Verrà avviato il debugger.

Poiché la Products_SelectByCategoryID stored procedure prevede un @CategoryID parametro di input, viene chiesto di specificare questo valore. Immettere 1, che restituirà informazioni sulle bevande.

@CategoryID Parametro" />

Figura 1: Usare il valore 1 per il @CategoryID parametro

Dopo aver specificato il valore per il @CategoryID parametro, viene eseguita la stored procedure. Anziché eseguire fino al completamento, tuttavia, il debugger interrompe l'esecuzione nella prima istruzione. Si noti la freccia gialla nel margine, che indica la posizione corrente nella stored procedure. È possibile visualizzare e modificare i valori dei parametri tramite la finestra di controllo o semplicemente passando il mouse sul nome del parametro nella stored procedure.

Figura 2: Il debugger è stato interrotto nella prima istruzione della stored procedure (fare clic per visualizzare l'immagine a dimensione intera)

Per eseguire la stored procedure un'istruzione alla volta, fare clic sul pulsante Passa Sopra nella Barra degli strumenti o premere il tasto F10. La Products_SelectByCategoryID stored procedure contiene una singola SELECT istruzione, quindi premendo F10 verrà eseguito il passaggio sull'unica istruzione e verrà completata l'esecuzione della stored procedure. Al termine della stored procedure, l'output verrà visualizzato nella finestra Output e il debugger verrà terminato.

Annotazioni

Il debug T-SQL avviene a livello di istruzione; non è possibile entrare in una istruzione SELECT.

Passaggio 2: Configurazione del sito Web per il debug dell'applicazione

Durante il debug di una stored procedure direttamente da Esplora server è comodo, in molti scenari è più interessante eseguire il debug della stored procedure quando viene chiamata dall'applicazione ASP.NET. È possibile aggiungere punti di interruzione a una stored procedure da Visual Studio e quindi avviare il debug dell'applicazione ASP.NET. Quando una stored procedure con punti di interruzione viene richiamata dall'applicazione, l'esecuzione si interromperà nel punto di interruzione e sarà possibile visualizzare e modificare i valori dei parametri della stored procedure ed eseguire le istruzioni, proprio come nel passaggio 1.

Prima di poter avviare il debug di stored procedure chiamate dall'applicazione, è necessario indicare all'applicazione Web di ASP.NET di integrarsi con il debugger di SQL Server. Per iniziare, fare clic con il pulsante destro del mouse sul nome del sito Web in Esplora soluzioni (ASPNET_Data_Tutorial_74_CS). Scegliere l'opzione Pagine delle proprietà dal menu di scelta rapida, selezionare la voce Opzioni di avvio a sinistra e selezionare la casella di controllo SQL Server nella sezione Debugger (vedere la figura 3).

Figura 3: Selezionare la casella di controllo SQL Server nelle pagine delle proprietà dell'applicazione (fare clic per visualizzare l'immagine a dimensione intera)

È inoltre necessario aggiornare la stringa di connessione del database usata dall'applicazione in modo che il pool di connessioni sia disabilitato. Quando una connessione a un database viene chiusa, l'oggetto corrispondente SqlConnection viene inserito in un pool di connessioni disponibili. Quando si stabilisce una connessione a un database, è possibile recuperare un oggetto connessione disponibile da questo pool invece di dover creare e stabilire una nuova connessione. Questo pool di oggetti di connessione è un miglioramento delle prestazioni ed è abilitato di default. Tuttavia, quando si esegue il debug si vuole disattivare il pool di connessioni perché l'infrastruttura di debug non viene ristabilita correttamente quando si lavora con una connessione che è stata prelevata dal pool.

Per disabilitare il pooling di connessioni, aggiorna NORTHWNDConnectionString in Web.config in modo che includa l'impostazione Pooling=false.

<connectionStrings>
    <add name="NORTHWNDConnectionString" connectionString=
        "Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;
            Integrated Security=True;User Instance=True;Pooling=false"
        providerName="System.Data.SqlClient" />
</connectionStrings>

Annotazioni

Al termine del debug di SQL Server tramite l'applicazione ASP.NET assicurarsi di ripristinare il pool di connessioni rimuovendo l'impostazione Pooling dalla stringa di connessione (o impostandola su Pooling=true ).

A questo punto l'applicazione ASP.NET è stata configurata per consentire a Visual Studio di eseguire il debug di oggetti di database di SQL Server quando richiamati tramite l'applicazione Web. Tutto ciò che rimane ora consiste nell'aggiungere un punto di interruzione a una stored procedure e avviare il debug.

Passaggio 3: Aggiunta di un punto di interruzione e di eseguire il debug

Aprire la Products_SelectByCategoryID stored procedure e impostare un punto di interruzione all'inizio dell'istruzione SELECT facendo clic sul margine nella posizione appropriata o posizionando il cursore all'inizio dell'istruzione SELECT e premendo F9. Come illustrato nella figura 4, il punto di interruzione viene visualizzato come cerchio rosso nel margine.

Figura 4: Impostare un punto di interruzione nella Products_SelectByCategoryID stored procedure (fare clic per visualizzare l'immagine a dimensione intera)

Per eseguire il debug di un oggetto di database SQL tramite un'applicazione client, è fondamentale che il database sia configurato per supportare il debug dell'applicazione. Quando si imposta un punto di interruzione per la prima volta, questa impostazione dovrebbe essere attivata automaticamente, ma è prudente eseguire il doppio controllo. Fare clic con il pulsante destro del mouse sul NORTHWND.MDF Nodo in Esplora Server. Il menu contestuale deve includere una voce di menu selezionata denominata Debugging dell'applicazione.

Figura 5: Verificare che l'opzione debug dell'applicazione sia abilitata

Dopo aver impostato il punto di interruzione e con l'opzione Debug dell'applicazione abilitata, siamo pronti a eseguire il debug della stored procedure quando viene chiamata dall'applicazione ASP.NET. Avviare il debugger passando al menu Debug e scegliendo Avvia debug, premendo F5 o facendo clic sull'icona di riproduzione verde nella barra degli strumenti. Verrà avviato il debugger e verrà avviato il sito Web.

La Products_SelectByCategoryID stored procedure è stata creata nel tutorial Utilizzo di stored procedure esistenti per il tutorial dei TableAdapters del DataSet tipizzato. La pagina Web corrispondente (~/AdvancedDAL/ExistingSprocs.aspx) contiene un GridView che visualizza i risultati che questa stored procedure restituisce. Visitare questa pagina tramite il browser. Al raggiungimento della pagina, il punto di interruzione nella Products_SelectByCategoryID stored procedure verrà raggiunto e il controllo verrà restituito a Visual Studio. Proprio come nel passaggio 1, è possibile eseguire le istruzioni della stored procedure e visualizzare e modificare i valori dei parametri.

Figura 6: La ExistingSprocs.aspx pagina visualizza inizialmente le bevande (fare clic per visualizzare l'immagine a dimensione intera)

Figura 7: È stato raggiunto il punto di interruzione della stored procedure (fare clic per visualizzare l'immagine a dimensione intera)

Come illustrato nella finestra di controllo nella figura 7, il valore del parametro @CategoryID è 1. Ciò è dovuto al fatto che la ExistingSprocs.aspx pagina visualizza inizialmente i prodotti nella categoria bevande, che ha un CategoryID valore pari a 1. Scegliere una categoria diversa dall'elenco a discesa. In questo modo viene eseguito un postback e viene eseguita nuovamente la Products_SelectByCategoryID stored procedure. Il punto di interruzione viene nuovamente raggiunto, ma questa volta il valore del parametro @CategoryID riflette la voce selezionata dell'elenco a discesa CategoryID.

Figura 8: Scegliere una categoria diversa dall'elenco Drop-Down (fare clic per visualizzare l'immagine a dimensione intera)

@CategoryID riflette la categoria selezionata dalla pagina Web" />

Figura 9: Il @CategoryID parametro riflette la categoria selezionata dalla pagina Web (fare clic per visualizzare l'immagine a dimensione intera)

Annotazioni

Se il punto di interruzione nella Products_SelectByCategoryID procedura memorizzata non viene raggiunto quando si visita la ExistingSprocs.aspx pagina, assicurarsi che la casella di controllo SQL Server sia stata selezionata nella sezione Debugger della pagina delle proprietà dell'applicazione ASP.NET, che il pool di connessioni sia stato disabilitato e che l'opzione di debug dell'applicazione del database sia abilitata. Se si verificano ancora problemi, riavviare Visual Studio e riprovare.

Debugging degli oggetti del database T-SQL su istanze remote

Il debug di oggetti di database tramite Visual Studio è piuttosto semplice quando l'istanza del database di SQL Server si trova nello stesso computer di Visual Studio. Tuttavia, se SQL Server e Visual Studio si trovano in computer diversi, è necessaria un'attenta configurazione per ottenere tutto il corretto funzionamento. Ci sono due attività principali affrontate:

• Assicurarsi che il login usato per connettersi al database tramite ADO.NET appartenga al ruolo sysadmin.
• Assicurarsi che l'account utente di Windows usato da Visual Studio nel computer di sviluppo sia un account di accesso di SQL Server valido che appartiene al sysadmin ruolo.

Il primo passaggio è relativamente semplice. Identificare innanzitutto l'account utente usato per connettersi al database dall'applicazione ASP.NET e quindi, da SQL Server Management Studio, aggiungere tale account di accesso al sysadmin ruolo.

La seconda attività richiede che l'account utente di Windows usato per eseguire il debug dell'applicazione sia un account di accesso valido nel database remoto. Tuttavia, c'è una probabilità che l'account di Windows con cui sei connesso alla workstation non sia un accesso valido a SQL Server. Invece di aggiungere un account di accesso specifico a SQL Server, è preferibile designare un account utente di Windows come account di debug di SQL Server. Quindi, per eseguire il debug degli oggetti di database di un'istanza remota di SQL Server, è necessario eseguire Visual Studio usando le credenziali dell'account di accesso di Windows.

Un esempio dovrebbe aiutare a chiarire le cose. Si supponga che sia presente un account di Windows denominato SQLDebug all'interno del dominio di Windows. Questo account deve essere aggiunto all'istanza remota di SQL Server come account di accesso valido e come membro del sysadmin ruolo. Quindi, per eseguire il debug dell'istanza remota di SQL Server da Visual Studio, è necessario eseguire Visual Studio come SQLDebug utente. A tale scopo, è possibile disconnettersi dalla workstation, eseguire di nuovo l'accesso come SQLDebuge avviare Visual Studio, ma un approccio più semplice consiste nell'accedere alla workstation usando le proprie credenziali e quindi usare runas.exe per avviare Visual Studio come SQLDebug utente. runas.exe consente l'esecuzione di un'applicazione specifica sotto la forma di un account utente diverso. Per avviare Visual Studio come SQLDebug, è possibile immettere l'istruzione seguente nella riga di comando:

runas.exe /user:SQLDebug "%PROGRAMFILES%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe"

Per una spiegazione più dettagliata su questo processo, vedere la Guida di Hitchhiker di William R. Vaughna Visual Studio e SQL Server, Seventh Edition.

Annotazioni

Se il computer di sviluppo esegue Windows XP Service Pack 2, sarà necessario configurare il firewall di connessione Internet per consentire il debug remoto. L'articolo Procedura: Abilitare il debug di SQL Server 2005 indica che questo richiede due passaggi: (a) Nel computer host di Visual Studio, è necessario aggiungere Devenv.exe all'elenco Eccezioni e aprire la porta TCP 135 e (b) Nel computer remoto (SQL), è necessario aprire la porta TCP 135 e aggiungere sqlservr.exe all'elenco Eccezioni. Se i criteri di dominio richiedono la comunicazione di rete tramite IPSec, è necessario aprire le porte UDP 4500 e UDP 500.

Riassunto

Oltre a fornire supporto per il debug per il codice dell'applicazione .NET, Visual Studio offre anche un'ampia gamma di opzioni di debug per SQL Server 2005. In questa esercitazione sono stati esaminati due di queste opzioni: Debug diretto del database e debug dell'applicazione. Per eseguire direttamente il debug di un oggetto di database T-SQL, individuare l'oggetto tramite Esplora server, quindi cliccare con il tasto destro su di esso e scegliere Passaggio interno. Viene avviato il debugger e viene interrotto sulla prima istruzione nell'oggetto di database, a questo punto è possibile procedere con l'esecuzione delle istruzioni dell'oggetto e visualizzare e modificare i valori dei parametri. Nel passaggio 1 abbiamo usato questo approccio per entrare nella Products_SelectByCategoryID stored procedure.

Il debug dell'applicazione consente di impostare punti di interruzione direttamente all'interno degli oggetti di database. Quando un oggetto di database con punti di interruzione viene richiamato da un'applicazione client (ad esempio un'applicazione Web ASP.NET), il programma si interrompe quando il debugger assume il controllo. Il debug dell'applicazione è utile perché mostra più chiaramente l'azione dell'applicazione che fa sì che venga richiamato un oggetto di database specifico. Tuttavia, richiede un po'più di configurazione e configurazione rispetto al debug diretto del database.

È anche possibile eseguire il debug degli oggetti di database tramite progetti di SQL Server. Si esaminerà l'uso di progetti DI SQL Server e come usarli per creare ed eseguire il debug di oggetti di database gestiti nell'esercitazione successiva.

Buon programmatori!

Informazioni sull'autore

Scott Mitchell, autore di sette libri ASP/ASP.NET e fondatore di 4GuysFromRolla.com, ha lavorato con le tecnologie Web Microsoft dal 1998. Scott lavora come consulente indipendente, formatore e scrittore. Il suo ultimo libro è Sams Teach Yourself ASP.NET 2.0 in 24 ore. Può essere raggiunto a mitchell@4GuysFromRolla.com.

PrecedenteAvanti