Transizioni di stato

ODBC definisce stati discreti per ogni ambiente, ogni connessione e ogni istruzione. Ad esempio, l'ambiente ha tre stati possibili: Non allocato (in cui non viene allocato alcun ambiente), Allocato (in cui un ambiente viene allocato ma non sono allocate connessioni) e Connessione (in cui vengono allocati un ambiente e una o più connessioni). Le connessioni hanno sette stati possibili; le istruzioni hanno 13 stati possibili.

Un particolare oggetto, come identificato dal relativo handle, passa da uno stato a un altro quando l'applicazione chiama una determinata funzione o più funzioni e passa l'handle a tale oggetto. Tale movimento viene chiamato transizione di stato. Ad esempio, l'allocazione di un handle di ambiente con SQLAllocHandle sposta l'ambiente da Non allocato ad Allocato e, liberando tale handle con SQLFreeHandle, lo ripristina da Allocato a Non allocato. ODBC definisce un numero limitato di transizioni di stato legali, un altro modo per dire che le funzioni devono essere chiamate in un determinato ordine.

Alcune funzioni, ad esempio SQLGet Connessione Attr, non influiscono affatto sullo stato. Altre funzioni influiscono sullo stato di un singolo elemento. Ad esempio, SQLDisconnect sposta una connessione da uno stato Connessione a uno stato Allocato. Infine, alcune funzioni influiscono sullo stato di più oggetti. Ad esempio, l'allocazione di un handle di connessione con SQLAllocHandle sposta una connessione da uno stato Non allocato a uno stato Allocato e sposta l'ambiente da uno stato Allocato a uno stato Connessione.

Se un'applicazione chiama una funzione in un ordine errato, la funzione restituisce un errore di transizione di stato. Ad esempio, se un ambiente si trova in uno stato Connessione e l'applicazione chiama SQLFreeHandle con tale handle di ambiente, SQLFreeHandle restituisce SQLSTATE HY010 (errore di sequenza di funzione), perché può essere chiamato solo quando l'ambiente è in uno stato Allocato. Definendo questa operazione come transizione di stato non valida, ODBC impedisce all'applicazione di liberare l'ambiente mentre sono presenti connessioni attive.

Alcune transizioni di stato sono intrinseche nella progettazione di ODBC. Ad esempio, non è possibile allocare un handle di connessione senza prima allocare un handle di ambiente, perché la funzione che alloca un handle di connessione richiede un handle di ambiente. Altre transizioni di stato vengono applicate da Gestione driver e dai driver. Ad esempio, SQLExecute esegue un'istruzione preparata. Se l'handle di istruzione passato non è in uno stato Preparato, SQLExecute restituisce SQLSTATE HY010 (errore di sequenza di funzione).

Dal punto di vista dell'applicazione, le transizioni di stato sono in genere semplici: le transizioni di stato legali tendono ad andare di pari passo con il flusso di un'applicazione ben scritta. Le transizioni di stato sono più complesse per Gestione driver e i driver perché devono tenere traccia dello stato dell'ambiente, di ogni connessione e di ogni istruzione. La maggior parte di queste operazioni viene eseguita da Gestione driver; la maggior parte delle operazioni che devono essere eseguite dai driver avviene con istruzioni con risultati in sospeso.

Le parti 1 e 2 di questo manuale ("Introduzione a ODBC" e "Sviluppo di applicazioni e driver") tendono a non menzionare esplicitamente le transizioni di stato. Descrivono, invece, l'ordine in cui devono essere chiamate le funzioni. Ad esempio, "Esecuzione di istruzioni" indica che un'istruzione deve essere preparata con SQLPrepare prima di poter essere eseguita con SQLExecute. Per una descrizione completa degli stati e delle transizioni di stato, comprese le transizioni controllate da Gestione driver e che devono essere controllate dai driver, vedere Appendice B: Tabelle di transizione di stato ODBC.