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 Connexion (dans laquelle un environnement et une ou plusieurs connexions sont allouées). Les connexions 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 SQLGetConnectAttr, 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 connexion à 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 état alloué vers un état de connexion.

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 connexion 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 ce travail est effectué par le Gestionnaire de pilotes ; la plupart des tâches que doivent accomplir les pilotes concerne des instructions ayant 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 vérifiées par le Gestionnaire de pilotes et qui doivent être vérifiées par les pilotes, consultez l’annexe B : Tables de transition d’état ODBC.