Esecuzione preparata
L'API ODBC definisce l'esecuzione preparata per ridurre l'overhead dell'analisi e della compilazione associato all'esecuzione ripetuta di un'istruzione Transact-SQL. Nell'applicazione viene creata una stringa di caratteri contenente un'istruzione SQL che viene eseguita in due fasi. Viene chiamato SQLPrepare una volta per analizzare e compilare l'istruzione in un piano di esecuzione mediante il Motore di database, quindi viene chiamato SQLExecute per ogni esecuzione del piano di esecuzione preparata con conseguente risparmio dell'overhead correlato all'analisi e alla compilazione in ogni esecuzione. L'esecuzione preparata viene generalmente utilizzata dalle applicazioni per eseguire ripetutamente la stessa istruzione SQL con parametri.
Per la maggior parte dei database, l'esecuzione preparata è più veloce dell'esecuzione diretta per le istruzioni eseguite più di tre o quattro volte, sopratutto perché l'istruzione viene compilata una sola volta, mentre le istruzioni eseguite direttamente vengono compilate ogni volta che vengono eseguite. L'esecuzione preparata può inoltre offrire una riduzione del traffico di rete perché il driver può inviare all'origine dati un identificatore del piano di esecuzione e i valori dei parametri, anziché un'intera istruzione SQL, ogni volta che viene eseguita l'istruzione.
Grazie all'implementazione di algoritmi migliorati per il rilevamento e il riutilizzo dei piani di esecuzione da SQLExecDirect, in SQL Server 2000 e versioni successive viene ridotta la differenza nelle prestazioni tra l'esecuzione diretta e l'esecuzione preparata, offrendo alle istruzioni eseguite direttamente alcuni dei vantaggi di prestazioni associati all'esecuzione preparata. Per ulteriori informazioni, vedere Esecuzione diretta.
In SQL Server 2000 e versioni successive è disponibile inoltre il supporto nativo per l'esecuzione preparata. Un piano di esecuzione viene generato con SQLPrepare e viene eseguito in un secondo momento mediante la chiamata a SQLExecute. Poiché in SQL Server 2000 e versioni successive non è necessario creare stored procedure temporanee con SQLPrepare, non è previsto alcun overhead aggiuntivo nelle tabelle di sistema di tempdb.
Per motivi di prestazioni, la preparazione dell'istruzione viene posticipata fino alla chiamata a SQLExecute o fino all'esecuzione di un'operazione di metaproprietà, ad esempio SQLDescribeCol o SQLDescribeParam in ODBC. Questo è il comportamento predefinito. Eventuali errori nell'istruzione da preparare verranno rilevati solo dopo l'esecuzione dell'istruzione o dell'operazione di metaproprietà. È possibile disattivare questo comportamento predefinito impostando l'attributo SQL_SOPT_SS_DEFER_PREPARE dell'istruzione specifica del driver ODBC di SQL Server Native Client su SQL_DP_OFF.
In caso di preparazione posticipata, se si chiama SQLDescribeCol o SQLDescribeParam prima di chiamare SQLExecute, viene generato un round trip aggiuntivo nel server. In SQLDescribeCol il driver rimuove la clausola WHERE dalla query inviandola al server con SET FMTONLY ON per ottenere la descrizione delle colonne nel primo set di risultati restituito dalla query. In SQLDescribeParam il driver chiama il server per ottenere una descrizione delle espressioni o delle colonne a cui fanno riferimento gli indicatori di parametro della query. Questo metodo presenta inoltre alcune restrizioni, ad esempio non è in grado di risolvere i parametri nelle sottoquery.
Un utilizzo eccessivo di SQLPrepare con il driver ODBC di SQL Server Native Client comporta una riduzione delle prestazioni, soprattutto se si è connessi alle versioni precedenti di SQL Server. L'esecuzione preparata non deve essere utilizzata per le istruzioni eseguite una sola volta. L'esecuzione preparata è più lenta dell'esecuzione diretta per una singola esecuzione di un'istruzione perché richiede un round trip in rete aggiuntivo dal client al server. Nelle versioni precedenti di SQL Server viene inoltre generata una stored procedure temporanea.
Le istruzioni preparate non possono essere utilizzate per creare oggetti temporanei in SQL Server 2000 o versioni successive o nelle versioni precedenti di SQL Server se è attiva l'opzione per generare le stored procedure. Se questa opzione è attivata, l'istruzione preparata viene creata in una stored procedure temporanea eseguita quando viene chiamato SQLExecute. Tutti gli oggetti temporanei creati durante l'esecuzione di una stored procedure vengono eliminati automaticamente al termine della procedura. In entrambi gli esempi seguenti la tabella temporanea #sometable non viene creata se è attiva l'opzione per generare le stored procedure:
SQLPrepare(hstmt,
"CREATE TABLE #sometable(cola int, colb char(8))",
SQL_NTS);
SQLExecute(hstmt);
oppure
SQLPrepare(hstmt,
"SELECT * FROM Authors INTO #sometable",
SQL_NTS);
SQLExecute(hstmt);
In alcune applicazioni ODBC precedenti ogni volta che si utilizzava SQLBindParameter veniva utilizzato SQLPrepare. SQLBindParameter non richiede l'utilizzo di SQLPrepare e può essere utilizzato con SQLExecDirect. Utilizzare ad esempio SQLExecDirect con SQLBindParameter per recuperare il codice restituito o i parametri di output da una stored procedure eseguita una sola volta. Non utilizzare SQLPrepare con SQLBindParameter a meno che la stessa istruzione non venga eseguita più volte.