Debug di stored procedure (VB)

di Scott Mitchell

Scarica il PDF

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

Introduzione

Visual Studio offre un'esperienza di debug avanzata. Con alcune sequenze di tasti o clic del mouse, è possibile usare punti di interruzione per arrestare l'esecuzione di un programma ed esaminarne lo stato e il flusso di controllo. Oltre al debug del codice dell'applicazione, Visual Studio offre il 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 code-behind ASP.NET o della classe Livello logica di business, in modo che possano essere inseriti anche all'interno di 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.

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 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 offrire 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. Ovvero, è possibile creare oggetti di database come stored procedure e funzioni User-Defined (UDF) come metodi in una classe Visual Basic. Ciò consente a queste stored procedure e funzioni definite dall'utente di usare le funzionalità in .NET Framework e dalle classi personalizzate. Naturalmente, SQL Server 2005 fornisce anche il supporto per gli oggetti di database T-SQL.

SQL Server 2005 offre il 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 di blog Panoramica del debug T-SQL e CLR in SQL Server 2005 del team di integrazione CLR di SQL Server 2005 illustra i tre modi per eseguire il debug di oggetti SQL Server 2005 da Visual Studio:

• Debug diretto del database : da Esplora server è possibile eseguire qualsiasi oggetto di database T-SQL, ad esempio stored procedure e funzioni definite dall'utente. Si esaminerà 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 verrà trasformato nel debugger. Si noti che con il debug dell'applicazione non è possibile eseguire l'istruzione in un oggetto di database dal codice dell'applicazione. È necessario impostare in modo esplicito i punti di interruzione in tali stored procedure o funzioni definite dall'utente in cui si vuole arrestare il debugger. Il debug delle applicazioni viene esaminato a partire dal passaggio 2.
• Il debug da un progetto SQL Server : Visual Studio Professional e le edizioni Team Systems includono un tipo di progetto SQL Server comunemente usato per creare oggetti di database gestiti. Si esaminerà l'uso di progetti SQL Server e ne verrà eseguito il debug nel contenuto nell'esercitazione successiva.

Visual Studio può eseguire il debug di stored procedure in istanze di SQL Server locali e remote. Un'istanza di SQL Server locale è una istanza installata nello stesso computer di Visual Studio. Se il database 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 di SQL Server remota, tuttavia, è prima di tutto 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 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ì ricco di funzionalità come il supporto per il 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: Eseguire direttamente l'istruzione in una stored procedure

Visual Studio semplifica il debug diretto di un oggetto di database. Si esamini ora come usare la funzionalità DDD (Direct Database Debugging) per eseguire l'istruzione della Products_SelectByCategoryID stored procedure nel database Northwind. Come suggerisce il nome, Products_SelectByCategoryID restituisce le informazioni sul prodotto per una determinata categoria, che è stata creata nell'esercitazione Using Existing Stored procedures for the Typed DataSet s TableAdapters . Per iniziare, passare a Esplora server ed espandere il nodo del database Northwind. Eseguire quindi il drill-down nella cartella Stored procedure, fare clic con il pulsante destro del Products_SelectByCategoryID mouse sulla stored procedure e scegliere l'opzione Esegui istruzione nella 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 Parameter" />

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

Dopo aver specificato il valore per il @CategoryID parametro , viene eseguita la stored procedure. Invece di 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 Espressione di controllo o passando il puntatore del 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 una sola istruzione alla volta, fare clic sul pulsante Esegui istruzione nella barra degli strumenti o premere F10. La Products_SelectByCategoryID stored procedure contiene una singola istruzione, quindi premendo F10 verrà eseguita l'istruzione singola SELECT 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.

Nota

Il debug T-SQL si verifica a livello di istruzione; non è possibile eseguire 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 è più interessante 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 viene richiamata una stored procedure con punti di interruzione dall'applicazione, l'esecuzione verrà interrotta nel punto di interruzione e sarà possibile visualizzare e modificare i valori dei parametri della stored procedure ed eseguire le istruzioni, esattamente 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 SQL Server. Per iniziare, fare clic con il pulsante destro del mouse sul nome del sito Web nel Esplora soluzioni (ASPNET_Data_Tutorial_74_VB). Scegliere l'opzione Pagine delle proprietà dal menu di scelta rapida, selezionare la voce Opzioni start 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 il database stringa di connessione usato 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 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 ricavata 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

Al termine del debug SQL Server tramite l'applicazione ASP.NET assicurarsi di ripristinare il pool di connessioni rimuovendo l'impostazione Pooling dal 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 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 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 configurare il database per supportare il debug dell'applicazione. Quando si imposta un punto di interruzione per la prima volta, questa impostazione deve essere attivata automaticamente, ma è consigliabile eseguire il doppio controllo. Fare clic con il pulsante destro del NORTHWND.MDF mouse sul nodo in Esplora server. Il menu di scelta rapida deve includere una voce di menu selezionata denominata Application Debugging .

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

Dopo aver impostato il punto di interruzione e l'opzione Debug applicazioni 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 verrà avviato il sito Web.

La stored procedure è stata creata nell'esercitazione Using Existing Stored procedure for the Typed DataSet s TableAdapters .The stored procedure was created in the Using Existing Stored procedures for the Typed DataSet s TableAdapters tutorial.Products_SelectByCategoryID 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à raggiunto e il controllo verrà restituito a Visual Studio. Proprio come nel passaggio 1, è possibile scorrere 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 Espressione di controllo nella figura 7, il valore del @CategoryID parametro è 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 si verifica un postback e si esegue nuovamente la Products_SelectByCategoryID stored procedure. Il punto di interruzione viene nuovamente raggiunto, ma questa volta il @CategoryID valore del parametro riflette la voce di elenco a discesa selezionata s 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)

Nota

Se il punto di interruzione nella Products_SelectByCategoryID stored procedure 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 proprietà dell'applicazione ASP.NET, il pool di connessioni è stato disabilitato e che l'opzione Debug applicazioni del database è abilitata. Se si verificano ancora problemi, riavviare Visual Studio e riprovare.

Debug di oggetti T-database SQL in istanze remote

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

• 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 SQL Server valido 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 di Windows con cui hai eseguito l'accesso alla workstation non sia un account di accesso valido in SQL Server. Invece di aggiungere un account di accesso specifico a SQL Server, è preferibile designare un account utente di Windows come account di debug SQL Server. Per eseguire quindi il debug degli oggetti di database di un'istanza di SQL Server remota, è 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 di SQL Server remota come account di accesso valido e come membro del sysadmin ruolo. Per eseguire il debug dell'istanza di SQL Server remota da Visual Studio, è quindi necessario eseguire Visual Studio come SQLDebug utente. A tale scopo, è possibile disconnettersi dalla workstation, accedere nuovamente come SQLDebuge quindi 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 una determinata applicazione 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.

Nota

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 SQL Server 2005 Debug nota che questa operazione prevede 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 che la comunicazione di rete venga eseguita tramite IPSec, è necessario aprire le porte UDP 4500 e UDP 500.

Riepilogo

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 fare clic con il pulsante destro del mouse su di esso e scegliere Esegui istruzione. In questo modo il debugger viene avviato e interrotto nella prima istruzione dell'oggetto di database, a questo punto è possibile scorrere le istruzioni dell'oggetto e visualizzare e modificare i valori dei parametri. Nel passaggio 1 è stato usato questo approccio per eseguire l'istruzione 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 viene interrotto man mano che il debugger assume il controllo. Il debug dell'applicazione è utile perché mostra più chiaramente l'azione dell'applicazione che causa la chiamata di 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 di oggetti di database tramite progetti di SQL Server. Si esaminerà l'uso di progetti 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, lavora 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 all'indirizzo mitchell@4GuysFromRolla.com. o tramite il suo blog, disponibile all'indirizzo http://ScottOnWriting.NET.

IndietroAvanti