Limitazioni del debug di SQL
Aggiornamento: novembre 2007
Le informazioni contenute in questo argomento sono valide per:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
|
|
Standard |
|
|
|
|
Pro e Team |
.gif) |
|
|
|
Legenda tabella:
|
Applicabile |
|
Non applicabile |
.gif) |
Comando o comandi nascosti per impostazione predefinita. |
Il debug SQL prevede una serie di limitazioni generali, descritte in questa sezione.
Debug SQL a più livelli
Quando si esegue il debug di applicazioni a più livelli, non è possibile utilizzare Esegui istruzione per eseguire il codice in SQL Server 2005 (T-SQL o CLR SQL) dal codice al livello dell'applicazione (C#, Visual Basic o C++). Procedere invece impostando un punto di interruzione nel codice della stored procedure, quindi premere Continua (F5) per eseguire il codice fino al punto di interruzione. È anche possibile utilizzare Esegui fino al cursore per raggiungere un punto desiderato, senza utilizzare un punto di interruzione. Al livello di SQL Server 2005, è possibile passare dal codice T-SQL al codice CLR SQL e viceversa.
Non è tuttavia possibile passare dal codice della stored procedure al codice presente al livello che ha chiamato la stored procedure. Per continuare ad eseguire il debug dopo essere tornati al livello dell'applicazione, impostare un punto di interruzione nel codice dell'applicazione dopo il punto da cui era stata chiamata la stored procedure.
Il pool di connessioni è una tecnica che consente di migliorare le prestazioni. Quando un'applicazione chiude la connessione dati, la connessione SQL Server non viene chiusa completamente, ma mantenuta in un pool riutilizzabile nel caso in cui l'applicazione tenti di riaprire la connessione in un secondo momento. Se tuttavia la connessione viene ristabilita mediante il pool di connessioni, il debug di SQL non verrà riattivato.
Disattivare temporaneamente il pool di connessioni durante il debug. A tale scopo, impostare "Pooling=false" nella stringa di connessione utilizzata per la connessione a SQL Server. Al termine del debug, rimuovere questo attributo dalla stringa di connessione. Il pool verrà attivato per impostazione predefinita.
Un'applicazione gestita può connettersi a un'origine dati SQL Server utilizzando il provider di dati .NET Framework di SQL Server che consente prestazioni migliori rispetto alla connessione a OLE DB o ODBC. Nella stessa sessione di debug è possibile eseguire sia il debug gestito che il debug di SQL.
Se è in esecuzione un'applicazione gestita e si esegue la connessione all'applicazione mediante il debugger, è possibile scegliere il tipo di debug da eseguire. Scegliere il debug SQL per eseguire questo tipo di debug, specificare invece il debug gestito per eseguire il debug di codice CLR SQL.
Il debug di SQL può essere effettuato dopo aver stabilito una connessione con un'applicazione in esecuzione. È possibile eseguire il debug solo delle connessioni a database create dopo il completamento della connessione. Pertanto, se un'applicazione chiama una stored procedure che richiede molto tempo, non è possibile stabilire la connessione che ha chiamato la stored procedure, ma solo nuove connessioni che chiamano la stored procedure dopo aver stabilito la connessione all'applicazione.
Se si esegue il debug tramite una connessione effettuata con OleDbDataAdapter, un'attesa troppo lunga dopo il raggiungimento di un punto di interruzione provocherà il timeout della connessione. Quando si tenta di continuare il debug dopo il timeout, ad esempio scegliendo Continua dal menu Debug, il debugger verrà chiuso e l'esecuzione verrà interrotta. Questo è il funzionamento previsto. Il debugger viene chiuso perché OleDbDataAdapter, diversamente da SqlDataAdapter, non genera un'eccezione quando si verifica un timeout. Per risolvere il problema, impostare il valore del timeout su un numero alto durante l'utilizzo di OleDbDataAdapter.
Per informazioni sull'impostazione del valore del timeout per i provider di dati .NET Framework, vedere Proprietà OleDbCommand.CommandTimeout e Proprietà SqlCommand.CommandTimeout nella documentazione Libreria di classi .NET Framework.
Per notizie aggiornate sulle tecnologie MDAC, visitare il sito Web Microsoft Universal Data Access all'indirizzo https://www.microsoft.com/data (informazioni in lingua inglese).
Altre limitazioni
Per essere sottoposti a debug i trigger devono prima essere generati: non è possibile eseguire direttamente il debug dei trigger. Avviare il debug in una stored procedure che causerà la generazione del trigger.
Nel corso del debug di runtime, il buffer di rete può essere compilato da una serie di sottoquery, ad esempio in un'unione. Di conseguenza, il codice che normalmente viene eseguito senza problemi può bloccarsi durante il debug. Per ottenere più dati, utilizzare RecordSet.MoveNext e RecordSet.NextRecordSet.
Se il nome di una stored procedure contiene delle virgolette, è possibile che venga visualizzato un messaggio di errore del debugger. Per ulteriori informazioni, vedere Errore durante il debug di procedure con nomi contenenti virgolette.
I valori presenti nella cache non vengono modificati automaticamente. Non sempre le modifiche apportate alle variabili locali o ai parametri presenti nella cache diverranno effettive nell'intervallo di tempo in cui si esegue un'istruzione SQL. Anche se si è modificato manualmente il valore, a causa del caching, le modifiche potrebbero non essere ancora visibili nel debug. Non è possibile forzare un aggiornamento dei valori presenti nella cache. Tali valori esistono in quanto secondo il piano di esecuzione di SQL Server i valori relativi ad alcune variabili non verranno caricati dinamicamente per l'esecuzione di ogni istruzione o per riferimento. Per ulteriori informazioni, eseguire una ricerca di "SHOWPLAN" nella documentazione relativa a SQL Server 2005.
Non è possibile connettersi al processo SQL Server nativo contemporaneamente al debug di una stored procedure.