Exportar (0) Imprimir
Expandir todo
Expandir Minimizar
Este artículo se tradujo de forma manual. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

TN042: Recomendaciones para desarrolladores de controladores ODBC

Nota Nota

La nota técnica siguiente no se ha actualizado desde que se incluyó por primera vez en la documentación en línea. Como resultado, algunos procedimientos y temas podrían estar obsoletos o ser incorrectos. Para obtener información más reciente, se recomienda buscar el tema de interés en el índice de la documentación en línea.

Esta nota describe las instrucciones para los programadores de controladores ODBC. Describe requisitos generales y supuestos de la funcionalidad de ODBC que las clases de base de datos MFC crean, y los distintos detalles semánticos esperados. La funcionalidad necesaria del controlador para admitir los tres modos abierto de CRecordset (forwardOnly, instantánea y dynaset) se describe.

Las clases de base de datos MFC muestran funcionalidad al usuario que en muchos casos supera la funcionalidad proporcionada por la mayoría de los controladores ODBC de nivel 1. Afortunadamente, la biblioteca de cursores ODBC se acodará entre las clases de base de datos y el controlador y, proporcionará automáticamente gran parte de esta funcionalidad adicional.

Por ejemplo, la mayoría 1,0 controladores no admiten el desplazamiento hacia atrás. La biblioteca de cursores puede detectar esto, y almacene en memoria caché filas de controlador y las mostrará como se solicitan en llamadas de FETCH_PREV en SQLExtendedFetch.

Otro ejemplo importante de la dependencia de la biblioteca de cursores es actualizaciones con ubicación. La mayoría 1,0 controladores tampoco tienen actualizaciones con ubicación, pero la biblioteca de cursores generará instrucciones de actualización que identifican una fila de destino en el origen de datos basado en los valores de datos en caché actuales, o una marca de tiempo almacenada en caché.

La biblioteca de clases nunca utiliza los conjuntos de filas. Por consiguiente, las pocas instrucciones de SQLSetPos siempre se aplican a la fila 1 de conjunto de filas.

Cada CDatabase asigna único HDBC. (Si se utiliza la función de CDatabaseExecuteSQL , HSTMT se asigna temporalmente.) Tan si se requiere entity_CODECDatabase múltiple, s múltiple de HDBCpor HENV debe admitirse.

Las clases de base de datos requieren la biblioteca de cursores. Esto se refleja en una llamada SQL_ODBC_CURSORS, SQL_CUR_USE_ODBCde SQLSetConnections .

SQLDriverConnect, SQL_DRIVER_COMPLETE es utilizado por CDatabase::Open para establecer la conexión al origen de datos.

El controlador debe admitir SQLGetInfo SQL_ODBC_API_CONFORMANCE >= SQL_OAC_LEVEL1, SQLGetInfo SQL_ODBC_SQL_CONFORMANCE >= SQL_OSC_MINIMUM.

Para que las transacciones admitidas para CDatabase y los conjuntos de registros dependientes, SQLGetInfo SQL_CURSOR_COMMIT_BEHAVIOR y SQL_CURSOR_ROLLBACK_BEHAVIOR deben tener SQL_CR_PRESERVE. Si no, los intentos de realizar el control de la transacción se omitirán.

SQLGetInfo SQL_DATA_SOURCE_READ_ONLY debe admitir. Si devuelve “y”, no se realizará ninguna operación de actualización en el origen de datos.

Si CDatabase es de sólo lectura abierta, un intento de establecer readonly del origen de datos se creará con SQLSetConnectOption SQL_ACCESS_MODE, SQL_MODE_READ_ONLY.

Si los identificadores requieren entrecomillado, esta información se debe devolver el controlador con una llamada de SQLGetInfoSQL_IDENTIFIER_QUOTE_CHAR .

A efectos de depuración, SQLGetInfo SQL_DBMS_VER y SQL_DBMS_NAME se recuperan del controlador.

SQLSetStmtOption SQL_QUERY_TIMEOUT y SQL_ASYNC_ENABLE se puede llamar CDatabaseHDBC.

SQLError se puede llamar con o todos los argumentos NULL.

Por supuesto, SQLAllocEnv, SQLAllocConnect, SQLDisconnect y SQLFreeConnect deben ser compatibles.

Además de asignar y de liberar HSTMTtemporal, ExecuteSQL llama SQLExecDirect, SQLFetch, SQLNumResultCol y SQLMoreResults. SQLCancel se puede llamar en HSTMT.

SQLGetInfo SQL_DATABASE_NAME se denominará.

SQLSetConnectOption SQL_AUTOCOMMIT y SQLTransact SQL_COMMIT, SQL_ROLLBACK y SQL_AUTOCOMMIT se llamará si se realizan las solicitudes de la transacción.

SQLAllocStmt, SQLPrepare, SQLExecute (For Abierta y Requery), SQLExecDirect (para las operaciones de actualización), SQLFreeStmt debe admitir. SQLNumResultCols y SQLDescribeCol se llama los resultados en distintas ocasiones.

SQLSetParam se usa mayoritariamente en los datos de parámetro y la funcionalidad de enlace de DATA_AT_EXEC .

SQLBindCol se usa mayoritariamente para registrar ubicaciones de almacenamiento de datos de columna de salida con ODBC.

Dos llamadas de SQLGetData se utilizan para recuperar los datos de SQL_LONG_VARCHAR y de SQL_LONG_VARBINARY . Los intentos de primera llamada buscar la longitud total del valor de la columna llamando a SQLGetData con el cbMaxValue de 0, pero con un pcbValue válido. Si el pcbValue contiene SQL_NO_TOTAL, se produce una excepción. Si no, se asigna HGLOBAL , y otra llamada a SQLGetData se hace para recuperar el resultado completo.

Si se solicita el bloqueo pesimista, SQLGetInfo SQL_LOCK_TYPES se consulta. Si SQL_LCK_EXCLUSIVE no se admite, se producirá una excepción.

Los intentos de actualizar CRecordset (instantánea o dynaset) producirán un segundo HSTMT que se asignará. Para los controladores que no admiten segundo HSTMT, la biblioteca de cursores simulará esta funcionalidad. Desgraciadamente, esto puede significar a veces forzar la consulta actual en primer HSTMT completamente antes de procesar la segunda solicitud de HSTMT .

SQLFreeStmt SQL_CLOSE y SQL_RESET_PARAMS y SQLGetCursorName se llamará durante las operaciones de actualización.

Si hay CLongBinarys en outputColumns, la funcionalidad de DATA_AT_EXEC de ODBC debe ser compatible. Esto incluye devolver SQL_NEED_DATA de SQLExecDirect, de SQLParamData y de SQLPutData.

SQLRowCount se denomina después de ejecutar para comprobar que solo 1 registro se actualizó por SQLExecDirect.

Sólo SQLFetch se requiere para las operaciones de Mover . Observe que los cursores de forwardOnly no admiten actualizaciones.

La funcionalidad de instantánea requiere compatibilidad con SQLExtendedFetch . Como se indicó anteriormente, la biblioteca de cursores ODBC detectará cuando un controlador no admite SQLExtendedFetch, y proporciona la compatibilidad necesaria propio.

SQLGetInfo, SQL_SCROLL_OPTIONS debe admitir SQL_SO_STATIC.

A continuación se muestra la compatibilidad mínimo necesario para abrir un conjunto:

SQLGetInfo, SQL_ODBC_VER debe devolver > “01 ".

SQLGetInfo, SQL_SCROLL_OPTIONS debe admitir SQL_SO_KEYSET_DRIVEN.

SQLGetInfo, SQL_ROW_UPDATES debe devolver “y”.

SQLGetInfo, SQL_POSITIONED_UPDATES debe admitir SQL_PS_POSITIONED_DELETE y SQL_PS_POSITIONED_UPDATE.

Además, si se solicita el bloqueo pesimista, una llamada a SQLSetPos con el irow 1, el fRefresh FALSE y la multitud SQL_LCK_EXCLUSIVE se lleve.

Adiciones de comunidad

AGREGAR
Mostrar:
© 2015 Microsoft