Transitions d’état

ODBC définit des états discrets pour chaque environnement, chaque connexion et chaque instruction. Par exemple, l’environnement a trois états possibles : non alloué (dans lequel aucun environnement n’est alloué), alloué (dans lequel un environnement est alloué, mais aucune connexion n’est allouée) et Connecter ion (dans lequel un environnement et une ou plusieurs connexions sont allouées). Connecter ions ont sept états possibles ; les instructions ont 13 états possibles.

Un élément particulier, tel qu’identifié par son handle, passe d’un état à un autre lorsque l’application appelle une certaine fonction ou fonctions et passe le handle à cet élément. Ce mouvement est appelé transition d’état. Par exemple, l’allocation d’un handle d’environnement avec SQLAllocHandle déplace l’environnement d’Unallocated vers Allocation, et la libération de ce handle avec SQLFreeHandle la retourne de Allocated à Unallocated. ODBC définit un nombre limité de transitions d’état légal, qui est une autre façon de dire que les fonctions doivent être appelées dans un certain ordre.

Certaines fonctions, telles que SQLGet Connecter Attr, n’affectent pas l’état du tout. D’autres fonctions affectent l’état d’un seul élément. Par exemple, SQLDisconnect déplace une connexion d’un état de Connecter ion vers un état alloué. Enfin, certaines fonctions affectent l’état de plusieurs éléments. Par exemple, l’allocation d’un handle de connexion avec SQLAllocHandle déplace une connexion d’un état non alloué vers un état alloué et déplace l’environnement d’un élément alloué vers un état de Connecter ion.

Si une application appelle une fonction hors ordre, la fonction retourne une erreur de transition d’état. Par exemple, si un environnement est dans un état de Connecter ion et que l’application appelle SQLFreeHandle avec ce handle d’environnement, SQLFreeHandle retourne SQLSTATE HY010 (erreur de séquence de fonction), car elle peut être appelée uniquement lorsque l’environnement est dans un état alloué. En définissant cela comme une transition d’état non valide, ODBC empêche l’application de libérer l’environnement pendant qu’il existe des connexions actives.

Certaines transitions d’état sont inhérentes à la conception d’ODBC. Par exemple, il n’est pas possible d’allouer un handle de connexion sans d’abord allouer un handle d’environnement, car la fonction qui alloue un handle de connexion nécessite un handle d’environnement. D’autres transitions d’état sont appliquées par le Gestionnaire de pilotes et les pilotes. Par exemple, SQLExecute exécute une instruction préparée. Si le handle d’instruction passé à celui-ci n’est pas dans un état Préparé, SQLExecute retourne SQLSTATE HY010 (erreur de séquence de fonction).

Du point de vue de l’application, les transitions d’état sont généralement simples : les transitions d’état juridiques ont tendance à aller de pair avec le flux d’une application bien écrite. Les transitions d’état sont plus complexes pour le Gestionnaire de pilotes et les pilotes, car elles doivent suivre l’état de l’environnement, chaque connexion et chaque instruction. La plupart de ces tâches sont effectuées par le Gestionnaire de pilotes ; la plupart du travail qui doit être effectué par les pilotes se produit avec des instructions avec des résultats en attente.

Les parties 1 et 2 de ce manuel (« Introduction à ODBC » et « Développement d’applications et de pilotes ») ne mentionnent pas explicitement les transitions d’état. Au lieu de cela, ils décrivent l’ordre dans lequel les fonctions doivent être appelées. Par exemple, « Instructions en cours d’exécution » indique qu’une instruction doit être préparée avec SQLPrepare avant de pouvoir être exécutée avec SQLExecute. Pour obtenir une description complète des états et des transitions d’état, y compris les transitions qui sont case activée par le Gestionnaire de pilotes et qui doivent être case activée par les pilotes, consultez l’annexe B : Tables de transition d’état ODBC.