Limitazioni del debug di Transact-SQL

Le informazioni contenute in questo argomento sono valide per:

Visual Studio Ultimate	Visual Studio Premium	Visual Studio Professional	Visual Studio Express

È opportuno considerare alcune limitazioni generali quando si esegue il debug di Transact-SQL con il debugger di Visual Studio e di SQL Server a partire da SQL Server 2005. Per ulteriori informazioni sul debug di Transact-SQL con SQL Server Management Studio, vedere Utilizzo del debugger Transact-SQL.

Debug di SQL a più livelli

• Quando si esegue il debug di applicazioni a più livelli, non è possibile utilizzare l'opzione Esegui istruzione per eseguire istruzioni dal codice del livello dell'applicazione (C#, Visual Basic o C++) al codice nell'istanza di SQL Server (Transact-SQL o SQL/CLR).Al contrario, è necessario impostare un punto di interruzione nel codice della stored procedure e premere Continua (F5) per eseguire codice fino al punto di interruzione.È possibile utilizzare anche Esegui fino al cursore per raggiungere un punto desiderato senza utilizzare un punto di interruzione.Si noti che all'interno del livello SQL Server è possibile spostarsi tra il codice Transact-SQL e il codice SQL/CLR.

• Inoltre, non è possibile spostarsi nell'altra direzione, ovvero dal codice della stored procedure al codice nel livello tramite cui è stata chiamata la stored procedure.Se si desidera continuare il debug dopo essere tornati al livello dell'applicazione, impostare un punto di interruzione nel codice dell'applicazione dopo il punto da cui è stata chiamata la stored procedure.

• Il pool di connessioni è una tecnica che consente di migliorare le prestazioni.Quando una connessione dati viene chiusa dalla relativa applicazione, la connessione di SQL Server non viene chiusa completamente, bensì viene mantenuta in un pool che può essere riutilizzato in un secondo momento se successivamente si verifica un nuovo tentativo di apertura della connessione da parte dell'applicazione.Tuttavia, quando una connessione viene ristabilita tramite un pool di connessioni, il debug Transact-SQL non viene riabilitato.

  È necessario disabilitare temporaneamente il pool di connessioni durante il debug.A tal fine, impostare "Pooling=false" nella stringa di connessione utilizzata per connettersi all'istanza di SQL Server.Al termine del debug, rimuovere questo attributo dalla stringa di connessione e il pool verrà abilitato per impostazione predefinita.

• Un'applicazione gestita può connettersi a un'origine dati di SQL Server tramite il Provider di dati .NET Framework per SQL Server che consente di ottenere prestazioni migliori rispetto alla connessione con OLE DB o ODBC.Nella stessa sessione del debugger è possibile eseguire sia il debug gestito sia il debug Transact-SQL.

  Se è in esecuzione un'applicazione gestita e si stabilisce una connessione all'applicazione tramite il debugger, è possibile scegliere il tipo di debug desiderato.Se si desidera eseguire il debug Transact-SQL, è necessario scegliere il debug Transact-SQL, mentre se si desidera eseguire il debug del codice SQL/CLR, è necessario specificare anche il debug gestito.

• È possibile eseguire il debug Transact-SQL dopo aver stabilito una connessione a un'applicazione in esecuzione.Tuttavia, si noti che è possibile eseguire il debug solo delle connessioni di database create dopo aver terminato l'operazione Connetti.Pertanto se tramite un'applicazione viene chiamata una stored procedure che sta richiedendo molto tempo, non è possibile collegarsi alla connessione tramite la quale è stata chiamata la stored procedure, bensì solo alle nuove connessioni tramite le quali viene chiamata la stored procedure dopo essersi connessi all'applicazione.

• Se si sta eseguendo il debug tramite una connessione eseguita con OleDbDataAdapter, un'attesa eccessiva dopo aver raggiunto un punto di interruzione comporterà il timeout della connessione.Quando si tenta di continuare il debug dopo questo timeout (ad esempio scegliendo Continua dal menu Debug), il debugger verrà chiuso, anziché consentire il proseguimento dell'esecuzione.Questo è il comportamento previsto.Il debugger viene chiuso perché tramite OleDbDataAdapter, a differenza di SqlDataAdapter, non viene generata alcuna eccezione quando si verifica un timeout.Per risolvere questo problema, impostare il valore di timeout su un numero elevato quando si utilizza OleDbDataAdapter.

  Per ulteriori informazioni sull'impostazione del valore di timeout per i provider di dati .NET Framework, vedere la proprietà OleDbCommand.CommandTimeout e la proprietà SqlCommand.CommandTimeout nella documentazione della libreria di classi .NET Framework.

Altre limitazioni

• Per poter essere sottoposti a debug, i trigger devono essere innanzitutto attivati, infatti non è possibile eseguirne direttamente il debug.Avviare quindi il debug in una stored procedure in modo che provochi l'attivazione del trigger.

• Nel debug in fase di esecuzione, una serie di selezioni secondarie (ad esempio in un'unione) può riempire il buffer di rete.Questa situazione può causare, durante il debug, l'interruzione del codice che in genere viene eseguito correttamente.Per ottenere più dati, utilizzare RecordSet.MoveNext e RecordSet.NextRecordSet.

• Se nel nome di una stored procedure sono contenute virgolette, si potrebbe ricevere un messaggio di errore del debugger.Per ulteriori informazioni, vedere Errore durante il debug di procedure con nomi contenenti virgolette.

• I valori memorizzati nella cache non vengono modificati automaticamente.Non si può sempre prevedere che le modifiche apportate alle variabili locali o ai parametri memorizzati nella cache dall'interprete di Transact-SQL saranno applicate durante l'intervallo di tempo in cui viene eseguita un'istruzione Transact-SQL.Anche se il valore è stato modificato, potrebbe non essere più controllato successivamente.Non è possibile forzare un aggiornamento dei valori memorizzati nella cache.I valori memorizzati nella cache esistono perché tramite il piano di esecuzione di SQL Server viene stabilito che i valori per alcune variabili non saranno caricati dinamicamente per ogni esecuzione o riferimento alle istruzioni.Per ulteriori informazioni, cercare "SHOWPLAN" nella documentazione di SQL Server.

• Non è possibile stabilire una connessione al processo nativo di SQL Server durante il debug di una stored procedure.

Vedere anche

Concetti

Debug di Transact-SQL

Limitazioni dei comandi e delle funzionalità del debugger

Altre risorse

Debugger Security