Actualizar un controlador de 3,5 a un controlador 3.8

En este tema se proporcionan instrucciones y consideraciones para actualizar un controlador ODBC 3.5 a un controlador ODBC 3.8.

Números de versión

Las siguientes directrices se relacionan con los números de versión:

• Un controlador debe admitir SQL_OV_ODBC3_80 para SQL_ATTR_ODBC_VERSION, devolviendo SQL_ERROR para valores distintos de SQL_OV_ODBC2, SQL_OV_ODBC3 y SQL_OV_ODBC3_80. En futuras versiones del Administrador de controladores se supone que un controlador admite un nivel de cumplimiento de ODBC si el controlador devuelve SQL_SUCCESS de la función SQLSetEnvAttr.

• Un controlador de la versión 3.8 debe devolver 03.80 de SQLGetInfo cuando se pasa SQL_DRIVER_ODBC_VER a InfoType. Sin embargo, los administradores de controladores anteriores, que se incluyeron en versiones anteriores de Microsoft Windows, tratarán el controlador como un controlador de la versión 3.5 y emitirán una advertencia.

  En Windows 7, la versión del Administrador de controladores es 03.80. En Windows 8, la versión del Administrador de controladores es 03.81 mediante SQL_DM_VER de SQLGetInfo (parámetro InfoType). SQL_ODBC_VER informa de la versión como 03.80 en Windows 7 y Windows 8.

Tipos de datos de C específicos del controlador

Un controlador puede tener tipos de datos C personalizados cuando funciona con una aplicación ODBC de la versión 3.8. (Para obtener más información, consulte Tipos de datos C en ODBC). Sin embargo, no es necesario que un controlador 3.8 implemente cualquier tipo de C específico del controlador. Pero el controlador debe seguir realizando la comprobación de rangos de tipos de C; el Administrador de controladores no lo hará para los controladores 3.8. Para facilitar el desarrollo de controladores, el valor del tipo de datos C específico del controlador se puede definir en el formato siguiente:

SQL_DRIVER_C_TYPE_BASE+0, SQL_DRIVER_C_TYPE_BASE+1  

Tipos de datos específicos del controlador, Descriptor tipos, tipos de información, tipos de diagnóstico y atributos

Al desarrollar un nuevo controlador, debe usar el intervalo específico del controlador para tipos de datos, tipos de descriptores, tipos de información, tipos de diagnóstico y atributos. Los intervalos específicos del controlador y sus valores de tipo base se describen en Tipos de datos específicos del controlador, tipos de descriptores, tipos de información, tipos de diagnóstico y atributos.

Agrupar conexiones

Para una mejor administración de la agrupación de conexiones, ODBC 3.8 introduce el atributo de conexión SQL_ATTR_RESET_CONNECTION en SQLSetConnectAttr. SQL_RESET_CONNECTION_YES es el único valor válido para este atributo. SQL_ATTR_RESET_CONNECTION se establecerá justo antes de que el Administrador de controladores coloque una conexión en el grupo de conexiones, lo que permite al controlador restablecer los demás atributos de conexión a sus valores predeterminados.

Para evitar la comunicación innecesaria con el servidor, un controlador puede aplazar el restablecimiento del atributo de conexión hasta la siguiente comunicación con el servidor remoto, después de reutilizar la conexión desde el grupo.

Tenga en cuenta que SQL_ATTR_RESET_CONNECTION solo se usa en la comunicación entre el Administrador de controladores y un controlador. Una aplicación no puede establecer este atributo directamente. Todos los controladores de la versión 3.8 deben implementar este atributo de conexión.

Parámetros de salida transmitidos

La versión 3.8 de ODBC presenta parámetros de salida transmitidos, una manera más escalable de recuperar los parámetros de salida. (Para obtener más información, consulte Recuperación de parámetros de salida mediante SQLGetData). Para admitir esta característica, un controlador debe establecer SQL_GD_OUTPUT_PARAMS en el valor devuelto cuando SQL_GETDATA_EXTENSIONS es InfoType en una llamada a SQLGetInfo. La compatibilidad con un tipo SQL con parámetros de salida transmitidos debe implementarse en el controlador. El Administrador de controladores no generará un error para un tipo SQL no válido. Los tipos SQL que admiten parámetros de salida transmitidos se definen en el controlador.

Un controlador debe devolver SQL_ERROR si la aplicación usó SQLGetData para recuperar un parámetro que no es el mismo que el parámetro devuelto por SQLParamData.

Ejecución asincrónica para operaciones de conexión (método de sondeo)

Un controlador puede habilitar la compatibilidad asincrónica con varias operaciones de conexión.

A partir de Windows 7, ODBC admite el método de sondeo (para obtener más información, vea Ejecución asincrónica (método de sondeo). No es necesario que un controlador ODBC de la versión 3.8 implemente operaciones asincrónicas en los identificadores de conexión. Incluso si un controlador no implementa operaciones asincrónicas en los identificadores de conexión, el controlador debe seguir implementando el InfoType de SQL_ASYNC_DBC_FUNCTIONS y devolver SQL_ASYNC_DBC_NOT_CAPABLE.

Cuando se habilitan las operaciones de conexión asincrónicas, el tiempo de ejecución de una operación de conexión es el tiempo total de todas las llamadas repetidas. Si la última llamada repetida se produce después de que el tiempo total haya superado el valor establecido por el atributo de conexión SQL_ATTR_CONNECTION_TIMEOUT y la operación no ha finalizado, el controlador devuelve SQL_ERROR y registra un registro de diagnóstico con SQLState HYT01 y el mensaje "Tiempo de espera de conexión expirado". No hay tiempo de expiración si la operación finalizó.

Función SQLCancelHandle

ODBC 3.8 admite la función SQLCancelHandle, que se usa para cancelar las operaciones de conexión e instrucción. Un controlador que admita SQLCancelHandle debe exportar la función. Un controlador no debe cancelar ninguna función de conexión sincrónica o asincrónica que esté en curso si la aplicación llama a SQLCancel o SQLCancelHandle en un identificador de instrucción. Del mismo modo, un controlador no debe cancelar ninguna función de instrucción sincrónica o asincrónica que esté en curso si una aplicación llama a SQLCancelHandle en el identificador de conexión. Además, un controlador no debe cancelar la operación de exploración (SQLBrowseConnect devuelve SQL_NEED_DATA) si la aplicación llama a SQLCancelHandle en el identificador de conexión. En estos casos, un controlador debe devolver HY010, "error de secuencia de funciones".

No es necesario admitir las operaciones de conexión asincrónica y SQLCancelHandle al mismo tiempo. Un controlador puede admitir operaciones de conexión asincrónicas, pero no SQLCancelHandle, o viceversa.

Conexiones suspendidas

El Administrador de controladores ODBC 3.8 puede poner una conexión en estado suspendido. Una aplicación llamará a SQLDisconnect para liberar los recursos asociados a la conexión. En este caso, un controlador debe intentar liberar tantos recursos como sea posible sin comprobar el estado de la conexión. Para obtener más información sobre el estado suspendido, vea Función SQLEndTran.

Agrupación de conexiones dependientes del controlador

ODBC en Windows 8 permite a los controladores personalizar el comportamiento del grupo de conexiones. Para obtener más información, vea Agrupación de conexiones compatibles con controladores.

Ejecución asincrónica (método de notificación)

ODBC 3.8 admite el método de notificación para las operaciones asincrónicas, disponibles a partir de Windows 8. Para obtener más información, vea Ejecución asincrónica (método de notificación).

Consulte también

Desarrollar un controlador ODBC
Controladores ODBC proporcionados por Microsoft
Novedades de ODBC 3.8