Transiciones de estado

ODBC define estados discretos para cada entorno, cada conexión y cada instrucción. Por ejemplo, el entorno tiene tres estados posibles: Sin asignar (en el que no se asigna ningún entorno), Asignado (en el que se asigna un entorno pero no se asignan conexiones) y Connection (en el que se asigna un entorno y una o varias conexiones). Las conexiones tienen siete estados posibles; las instrucciones tienen 13 estados posibles.

Un elemento determinado, tal como se identifica mediante su identificador, pasa de un estado a otro cuando la aplicación llama a una determinada función o funciones y pasa el identificador a ese elemento. Este movimiento se denomina transición de estado. Por ejemplo, la asignación de un identificador de entorno con SQLAllocHandle mueve el entorno de Sin asignar a Asignado y liberarlo con SQLFreeHandle lo devuelve de Asignado a Sin asignar. ODBC define un número limitado de transiciones de estado legal, que es otra manera de decir que se debe llamar a funciones en un orden determinado.

Algunas funciones, como SQLGetConnectAttr, no afectan al estado en absoluto. Otras funciones afectan al estado de un solo elemento. Por ejemplo, SQLDisconnect mueve una conexión de un estado de Conexión a un estado Asignado. Por último, algunas funciones afectan al estado de más de un elemento. Por ejemplo, asignar un identificador de conexión con SQLAllocHandle mueve una conexión de un estado No asignado a un estado Asignado y mueve el entorno de un objeto Asignado a un estado de Conexión.

Si una aplicación llama a una función desordenada, la función devuelve un error de transición de estado. Por ejemplo, si un entorno está en un estado de Conexión y la aplicación llama a SQLFreeHandle con ese identificador de entorno, SQLFreeHandle devuelve SQLSTATE HY010 (error de secuencia de funciones), ya que solo se puede llamar cuando el entorno está en un estado Asignado. Al definir esto como una transición de estado no válida, ODBC impide que la aplicación libere el entorno mientras haya conexiones activas.

Algunas transiciones de estado son inherentes al diseño de ODBC. Por ejemplo, no es posible asignar un identificador de conexión sin asignar primero un identificador de entorno, ya que la función que asigna un identificador de conexión requiere un identificador de entorno. El Administrador de controladores y los controladores aplican otras transiciones de estado. Por ejemplo, SQLExecute ejecuta una instrucción preparada. Si el identificador de instrucción que se le pasa no está en estado Preparado, SQLExecute devuelve SQLSTATE HY010 (Error de secuencia de función).

Desde el punto de vista de la aplicación, las transiciones de estado suelen ser sencillas: las transiciones de estado legal suelen acompañar al flujo de una aplicación escrita correctamente. Las transiciones de estado son más complejas para el Administrador de controladores y los controladores, ya que deben realizar un seguimiento del estado del entorno, cada conexión y cada instrucción. La mayor parte de este trabajo lo realiza el Administrador de controladores; la mayoría del trabajo que deben realizar los controladores se produce con instrucciones con resultados pendientes.

Las partes 1 y 2 de este manual ("Introducción a ODBC" y "Desarrollo de aplicaciones y controladores") tienden a no mencionar explícitamente transiciones de estado. En su lugar, describen el orden en el que se debe llamar a las funciones. Por ejemplo, "Ejecución de instrucciones" establece que una instrucción debe estar preparada con SQLPrepare para poder ejecutarse con SQLExecute. Para obtener una descripción completa de los estados y las transiciones de estado, incluidas las transiciones que comprueba el Administrador de controladores y cuáles deben comprobarse por los controladores, vea Apéndice B: Tablas de transición de estado de ODBC.