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), Allocate (in cui un ambiente viene allocato ma non sono allocate connessioni) e Connection (in cui vengono allocate un ambiente e una o più connessioni). Le connessioni hanno sette stati possibili; le istruzioni hanno 13 stati possibili.

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

Alcune funzioni, ad esempio SQLGetConnectAttr, non influiscono affatto sullo stato. Altre funzioni influiscono sullo stato di un singolo elemento. Ad esempio, SQLDisconnect sposta una connessione da uno stato Connection a uno stato Allocato. Infine, alcune funzioni influiscono sullo stato di più di un elemento. 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 allocato a uno stato di connessione.

Se un'applicazione chiama una funzione non in ordine, la funzione restituisce un errore di transizione dello stato. Ad esempio, se un ambiente è in uno stato Connection 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 dal Gestore dei 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 a passare a mano con il flusso di un'applicazione ben scritta. Le transizioni di stato sono più complesse per il Gestore driver e i driver perché devono tenere traccia dello stato dell'ambiente, di ogni connessione e di ogni dichiarazione. La maggior parte di queste operazioni viene eseguita dal Gestore dei driver; la maggior parte del lavoro che deve essere svolto dai driver si verifica 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, incluse le transizioni controllate da Gestione driver e che devono essere controllate dai driver, vedere Appendice B: Tabelle di transizione dello stato ODBC.