Debug di oggetti di database CLR
SQL Server offre il supporto per il debug di oggetti Transact-SQL e CLR (Common Language Runtime) nel database. Gli aspetti principali del debug in SQL Server sono la facilità di installazione e utilizzo e l'integrazione del debugger di SQL Server con il debugger di Microsoft Visual Studio. Inoltre, il debug funziona tra linguaggi diversi. Gli utenti possono passare senza problemi agli oggetti CLR da Transact-SQL e viceversa. Il debugger Transact-SQL di SQL Server 2008 in SQL Server Management Studio non può essere utilizzato per eseguire il debug di oggetti di database gestiti, ma è possibile eseguire il debug degli oggetti tramite i debugger disponibili in Visual Studio 2005 Professional Edition e Visual Studio 2005 Team Suite Edition. Il debug di oggetti di database gestiti in Visual Studio supporta tutte le funzionalità di debug comuni, ad esempio l'esecuzione di istruzioni e routine all'interno di routine in esecuzione nel server. Tramite i debugger è possibile impostare punti di interruzione, controllare lo stack di chiamate, controllare le variabili e modificarne i valori durante il debug. Si noti che non è possibile utilizzare Visual Studio .NET 2003 per la programmazione o il debug dell'integrazione CLR. In SQL Server è preinstallato .NET Framework e non è possibile utilizzare assembly di .NET Framework 2.0 in Visual Studio .NET 2003.
Per ulteriori informazioni sul debug del codice gestito tramite Visual Studio, vedere l'argomento "Debug del codice gestito" nella documentazione di Visual Studio.
Debug di autorizzazioni e restrizioni
Il debug è un'operazione che richiede privilegi elevati, pertanto in SQL Server è consentita solo ai membri del ruolo predefinito del server sysadmin.
Durante il debug vengono applicate le restrizioni seguenti:
Il debug di routine CLR è limitato a un'istanza di debugger alla volta. Questa limitazione viene applicata poiché qualsiasi esecuzione di codice CLR si blocca quando viene raggiunto un punto di interruzione e non continua finché il debugger non supera il punto di interruzione. Tuttavia, è possibile continuare il debug di Transact-SQL in altre connessioni. Benché il debug di Transact-SQL non blocchi altre esecuzioni nel server, può causare l'attesa di altre connessioni mantenendo un blocco.
Non è possibile eseguire il debug delle connessioni esistenti, ma solo di quelle nuove, poiché SQL Server richiede informazioni sul client e sull'ambiente del debugger prima di poter stabilire la connessione.
A causa delle restrizioni indicate sopra, si consiglia di eseguire il debug del codice Transact-SQL e di CLR in un server di prova, non in un server di produzione.
Cenni preliminari sul debug di oggetti di database gestiti
Il debug in SQL Server si basa su un modello per connessione. Un debugger può rilevare le attività ed eseguirne il debug solo nella connessione client a cui è connesso. Poiché la funzionalità del debugger non è limitata dal tipo di connessione, è possibile eseguire il debug sia di connessioni del flusso TDS sia di connessioni HTTP. Tuttavia, SQL Server non consente il debug delle connessioni esistenti. Il debug supporta tutte le funzionalità di debug comuni all'interno di routine in esecuzione nel server. L'interazione tra un debugger e SQL Server viene effettuata tramite Component Object Model (COM).
Per ulteriori informazioni e scenari relativi al debug di oggetti gestiti, quali stored procedure, funzioni, trigger, tipi definiti dall'utente e aggregazioni, vedere l'argomento Esecuzione del debug del database di integrazione CLR SQL Server nella documentazione di Visual Studio.
[!NOTA]
È necessario abilitare il protocollo di rete TCP/IP nell'istanza di SQL Server per utilizzare Visual Studio per lo sviluppo e il debug remoti. Per ulteriori informazioni sull'abilitazione del protocollo TCP/IP nel server, vedere Configurazione dei protocolli di rete client.
Per eseguire il debug di un oggetto di database gestito
Aprire Microsoft Visual Studio 2005, creare un nuovo progetto SQL Server e stabilire una connessione a un database in un'istanza di SQL Server.
Creare un nuovo tipo. In Esplora soluzioni, fare clic con il pulsante destro del mouse sul progetto, scegliere Aggiungi e Nuovo elemento.... Nella finestra Aggiungi nuovo elemento, selezionare Stored procedure, Funzione definita dall'utente, Tipo definito dall'utente, Trigger, Aggregazione o Classe. Specificare un nome per il file di origine del nuovo tipo e fare clic su Aggiungi.
Aggiungere il codice per il nuovo tipo nell'editor di testo. Per un codice di esempio relativo a un esempio di stored procedure, vedere la sezione più avanti in questo argomento.
Aggiungere uno script di test per il tipo. In Esplora soluzioni, espandere la directory TestScripts, fare doppio clic su Test.sql per aprire il file di origine dello script di test predefinito. Aggiungere nell'editor di testo uno script di test che richiama il codice di cui eseguire il debug. Di seguito viene fornito uno script di esempio.
Inserire uno o più punti di interruzione nel codice sorgente. Fare clic con il pulsante destro del mouse su una riga di codice nell'editor di testo, all'interno della funzione o della routine di cui eseguire il debug, quindi selezionare Punto di interruzione e Inserisci punto di interruzione. Il punto di interruzione viene aggiunto e la riga di codice viene evidenziata in rosso.
Scegliere Avvia debug dal menu Debug per compilare, distribuire e testare il progetto. Verrà eseguito lo script di test in Test.sql e verrà richiamato l'oggetto di database gestito.
Quando la freccia gialla che indica il puntatore all'istruzione viene visualizzata in corrispondenza del punto di interruzione, l'esecuzione del codice viene sospesa ed è possibile avviare il debug dell'oggetto di database gestito. È possibile scegliere Esegui istruzione/routine dal menu Debug per fare avanzare il puntatore all'istruzione alla successiva riga di codice. Nella finestra Variabili locali è possibile osservare lo stato degli oggetti attualmente evidenziati dal puntatore all'istruzione. È possibile aggiungere le variabili nella finestra Espressione di controllo. È possibile osservare lo stato delle variabili controllate durante l'intera sessione di debug, non solo quando la variabile si trova nella riga di codice attualmente evidenziata dal puntatore all'istruzione. Scegliere Continua dal menu Debug per fare avanzare il puntatore all'istruzione al successivo punto di interruzione o per completare l'esecuzione della routine se non sono presenti altri punti di interruzione.
Esempio
Nell'esempio seguente viene restituita al chiamante la versione di SQL Server.
C#
using System;
using System.Data;
using System.Data.SqlTypes;
using System.Data.SqlClient;
using Microsoft.SqlServer.Server;
public class StoredProcedures
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static void GetVersion()
{
using(SqlConnection connection = new SqlConnection("context connection=true"))
{
connection.Open();
SqlCommand command = new SqlCommand("select @@version",
connection);
SqlContext.Pipe.ExecuteAndSend(command);
}
}
}
Visual Basic
Imports System
Imports System.Data
Imports System.Data.Sql
Imports System.Data.SqlTypes
Imports Microsoft.SqlServer.Server
Imports System.Data.SqlClient
Partial Public Class StoredProcedures
<Microsoft.SqlServer.Server.SqlProcedure> _
Public Shared Sub GetVersion()
Using connection As New SqlConnection("context connection=true")
connection.Open()
Dim command As New SqlCommand("SELECT @@VERSION", connection)
SqlContext.Pipe.ExecuteAndSend(command)
End Using
End Sub
End Class
Di seguito viene fornito uno script di test che richiama la stored procedure GetVersion definita sopra.
EXEC GetVersion
Vedere anche