Debug di stored procedure (C#)

di Scott Mitchell

Scarica il PDF

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

Introduzione

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

In questa esercitazione si esaminerà l'esecuzione di stored procedure da Esplora server all'interno di Visual Studio e su come impostare i punti di interruzione che si verificano quando viene chiamata la stored procedure dall'applicazione ASP.NET in esecuzione.

Nota

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 insieme i passaggi necessari per eseguire il debug delle stored procedure, ma non sarà possibile replicare questi passaggi nel computer.

concetti di debug 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. Vale a dire, è possibile creare oggetti di database come stored procedure e funzioni di User-Defined come metodi in una classe C#. In questo modo queste stored procedure e UDFs possono usare funzionalità in .NET Framework e dalle proprie classi personalizzate. Naturalmente, SQL Server 2005 offre anche il supporto per gli oggetti di database T-SQL.

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

Panoramica del debug T-SQL e CLR nella voce di blog SQL Server 2005 dal team di integrazione CLR di SQL Server 2005 evidenzia i tre modi per eseguire il debug di oggetti SQL Server 2005 da Visual Studio:

• Debug diretto del database ( DDD): da Esplora server è possibile passare a qualsiasi oggetto di database T-SQL, ad esempio stored procedure e UDFs. 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à colpito e controllato a cui viene eseguito il debugger. Si noti che con il debug dell'applicazione non è possibile passare a un oggetto di database dal codice dell'applicazione. È necessario impostare in modo esplicito i punti di interruzione in tali stored procedure o UDF in cui si vuole che il debugger venga arrestato. Il debug delle applicazioni viene esaminato a partire dal passaggio 2.
• Il debug da un progetto SQL Server : Visual Studio Professional e edizioni di Team Systems includono un tipo di progetto SQL Server comunemente usato per creare oggetti di database gestiti. Verrà esaminato l'uso di progetti SQL Server e il debug del contenuto nell'esercitazione successiva.

Visual Studio può eseguire il debug di stored procedure in istanze locali e remote SQL Server. Un'istanza di SQL Server locale è quella installata nello stesso computer di Visual Studio. Se il database SQL Server usato non si trova nel computer di sviluppo, viene considerato un'istanza remota. Per queste esercitazioni sono state usati 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 e usare questa esercitazione alla fine. Se si usa un'istanza remota di SQL Server, tuttavia, è prima necessario assicurarsi che quando si esegue il debug nel computer di sviluppo con un account utente di Windows con un account utente di Windows con un accesso SQL Server nell'istanza remota. Inoltre, sia questo account di accesso al database che l'account di accesso al database usato per connettersi al database dall'applicazione ASP.NET in esecuzione devono essere membri del sysadmin ruolo. Vedere la sezione Debug di oggetti T-database 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 per il debug per gli oggetti di database T-SQL non è così avanzato come supporto per il debug per le applicazioni .NET. Ad esempio, le condizioni dei punti di interruzione e i filtri non sono supportati, sono disponibili solo un subset delle finestre di debug, non è possibile usare Modifica e Continua, la finestra Immediata viene resa inutile e così via. Per altre informazioni, vedere Limitazioni per i comandi e le funzionalità del debugger .

Passaggio 1: Passaggio diretto in una stored procedure

Visual Studio semplifica il debug diretto di un oggetto di database. Si esaminerà come usare la funzionalità Debug del database diretto (DDD) per eseguire l'esecuzione della Products_SelectByCategoryID stored procedure nel database Northwind. Poiché il nome implica, Products_SelectByCategoryID restituisce le informazioni sul prodotto per una determinata categoria. È stato creato nell'esercitazione Using Existing Stored Procedure per l'esercitazione TableAdapters di Typed DataSet. Iniziare passando a Esplora server e espandere il nodo del database Northwind. Eseguire quindi il drill-down nella cartella Stored Procedure, fare clic con il pulsante destro del mouse Products_SelectByCategoryID sulla stored procedure e scegliere l'opzione Passaggio 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 fornito il valore per il @CategoryID parametro, viene eseguita la stored procedure. Anziché eseguire il completamento, tuttavia, il debugger arresta 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 Watch o passando il puntatore del mouse sul nome del parametro nella stored procedure.

Figura 2: Il debugger si è arrestato nella prima istruzione della stored procedure (fare clic per visualizzare l'immagine a dimensioni complete)

Per eseguire la stored procedure un'istruzione alla volta, fare clic sul pulsante Passaggio sulla barra degli strumenti o premere il tasto F10. La Products_SelectByCategoryID stored procedure contiene un'unica SELECT istruzione, quindi il raggiungimento di F10 eseguirà il passaggio sull'istruzione singola e completa l'esecuzione della stored procedure. Al termine della stored procedure, l'output verrà visualizzato nella finestra Output e il debugger verrà terminato.

Nota

Il debug T-SQL si verifica a livello di istruzione; non è possibile passare a un'istruzione SELECT .

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

Durante il debug di una stored procedure direttamente da Esplora server è utile, in molti scenari si è più interessati a eseguire il debug della stored procedure quando viene chiamato 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 arresterà al punto di interruzione e sarà possibile visualizzare e modificare i valori dei parametri della stored procedure e eseguire le istruzioni, proprio come nel passaggio 1.

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

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

È inoltre necessario aggiornare il database stringa di connessione usato dall'applicazione in modo che il pool di connessioni sia disabilitato. Quando viene chiusa una connessione a un database, l'oggetto corrispondente SqlConnection viene inserito in un pool di connessioni disponibili. Quando si stabilisce una connessione a un database, un oggetto di connessione disponibile può essere recuperato da questo pool anziché dover creare e stabilire una nuova connessione. Questo pool di oggetti di connessione è un miglioramento delle prestazioni ed è abilitato per impostazione predefinita. Tuttavia, quando si esegue il debug si vuole disattivare il pool di connessioni perché l'infrastruttura di debug non viene ripristinata correttamente quando si lavora con una connessione che è stata eseguita dal pool.

Per disabilitare il pool di connessioni, aggiornare in NORTHWNDConnectionStringWeb.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>

Nota

Dopo aver completato il debug SQL Server tramite l'applicazione ASP.NET assicurarsi di ripristinare il pool di connessioni rimuovendo l'impostazione Pooling dall'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 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 debug

Aprire la Products_SelectByCategoryID stored procedure e impostare un punto di interruzione all'inizio dell'istruzione facendo clic sul margine nella posizione appropriata o posizionando il cursore all'inizio dell'istruzione SELECTSELECT 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 full-size)

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

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

Con il set di punti di interruzione e l'opzione Debug dell'applicazione abilitata, è possibile eseguire il debug della stored procedure quando viene chiamato dall'applicazione ASP.NET. Avviare il debugger passando al menu Debug e scegliendo Avvia debug, premendo F5 oppure facendo clic sull'icona di riproduzione verde nella barra degli strumenti. Verrà avviato il debugger e avviato il sito Web.

La Products_SelectByCategoryID stored procedure è stata creata nell'esercitazione Uso di stored procedure esistenti per l'esercitazione TableAdapters di DataSet tipizzato . La pagina Web corrispondente (~/AdvancedDAL/ExistingSprocs.aspx) contiene Un controllo GridView che visualizza i risultati restituiti da questa stored procedure. Visitare questa pagina tramite il browser. Al raggiungimento della pagina, il punto di interruzione nella Products_SelectByCategoryID stored procedure verrà colpito e controllato restituito a Visual Studio. Analogamente al passaggio 1, è possibile eseguire le istruzioni e 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 dimensioni complete)

Figura 7: Il punto di interruzione della stored procedure è stato raggiunto (fare clic per visualizzare l'immagine a dimensioni complete)

Come illustrato nella finestra Watch nella figura 7, il valore del @CategoryID parametro è 1. Questo perché la ExistingSprocs.aspx pagina visualizza inizialmente i prodotti nella categoria bevande, che ha un valore pari a CategoryID 1. Scegliere una categoria diversa dall'elenco a discesa. In questo modo viene generato un postback e viene eseguito nuovamente la Products_SelectByCategoryID stored procedure. Il punto di interruzione viene nuovamente raggiunto, ma questa volta il @CategoryID valore del parametro riflette l'elemento elenco a discesa selezionato s CategoryID.

Figura 8: scegliere una categoria diversa dall'elenco Drop-Down (fare clic per visualizzare l'immagine a dimensioni complete)

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 dimensioni complete)

Nota

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

Debug di oggetti T-database SQL in istanze remote

Il debug di oggetti di database tramite Visual Studio è abbastanza semplice quando l'istanza del database SQL Server si trova nello stesso computer di Visual Studio. Tuttavia, se SQL Server e Visual Studio risiedono in computer diversi, è necessaria una configurazione attenta per ottenere tutto correttamente. Ci sono due attività principali a cui ci si trova di fronte:

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

Il primo passaggio è relativamente semplice. Identificare prima di tutto 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, è probabile che l'account Windows connesso alla workstation con non sia un account di accesso valido in SQL Server. Anziché aggiungere l'account di accesso specifico a SQL Server, una scelta migliore consiste nel designare un account utente di Windows come account di debug SQL Server. Quindi, per eseguire il debug degli oggetti di database di un'istanza remota di SQL Server, si eseguirà 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 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. Questa operazione può essere eseguita disconnettendosi dalla workstation, eseguendo la registrazione in come SQLDebuge quindi avviando 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 veste 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 William R. Vaughn'sHitchhiker guide to Visual Studio and SQL Server, Seventh Edition.

Nota

Se il computer di sviluppo esegue Windows XP Service Pack 2, sarà necessario configurare Il firewall connessione Internet per consentire il debug remoto. L'articolo Procedura: Abilitare SQL Server 2005 Debug note che comporta 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 da eseguire tramite IPSec, è necessario aprire le porte UDP 4500 e UDP 500.

Riepilogo

Oltre a fornire il supporto per il debug per il codice dell'applicazione .NET, Visual Studio offre anche diverse opzioni di debug per SQL Server 2005. In questa esercitazione sono stati esaminati due di queste opzioni: Debug del database diretto e debug dell'applicazione. Per eseguire direttamente il debug di un oggetto database T-SQL, individuare l'oggetto tramite Esplora server e quindi fare clic con il pulsante destro del mouse su di esso e scegliere Passaggio in. Viene avviato il debugger e si arresta nella prima istruzione nell'oggetto di database, a questo punto è possibile eseguire le istruzioni dell'oggetto e visualizzare e modificare i valori dei parametri. Nel passaggio 1 è stato usato questo approccio per passare alla Products_SelectByCategoryID stored procedure.

Il debug delle applicazioni consente di impostare i 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 arresta quando il debugger assume. Il debug dell'applicazione è utile perché mostra più chiaramente l'azione dell'applicazione che causa un determinato oggetto di database da richiamare. Tuttavia, richiede un po'più di configurazione e configurazione rispetto al debug del database diretto.

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

Programmazione felice!

Informazioni sull'autore

Scott Mitchell, autore di sette libri ASP/ASP.NET e fondatore di 4GuysFromRolla.com, ha lavorato con le tecnologie Microsoft Web dal 1998. Scott lavora come consulente indipendente, allenatore e scrittore. Il suo ultimo libro è Sams Teach Yourself ASP.NET 2,0 in 24 Ore. Può essere raggiunto a mitchell@4GuysFromRolla.com. o tramite il suo blog, che può essere trovato in http://ScottOnWriting.NET.

IndietroAvanti