Problemas de rendimiento del controlador de base de datos de escritorio

Para garantizar la compatibilidad con las aplicaciones ANSI existentes, los tipos de datos de SQL_WCHAR, SQL_WVARCHAR y SQL_WLONGVARCHAR se exponen como SQL_CHAR, SQL_VARCHAR y SQL_LONGVARCHAR para orígenes de datos de Microsoft Access 4.0 o posteriores. Los orígenes de datos no devuelven tipos de datos WIDE CHAR, pero los datos todavía deben enviarse a Jet en formato Wide Char. Es importante comprender que la conversión se realizará si un parámetro de SQL_C_CHAR o columna de resultado está enlazado a un tipo de datos SQL_CHAR en una aplicación ANSI.

Esta conversión puede ser especialmente ineficaz en términos de memoria cuando un tipo SQL_C_CHAR está enlazado a un parámetro de tipo LONGVARCHAR. Dado que el motor Jet 4.0 no puede transmitir datos de parámetros LONGTEXT, se debe asignar un búfer de conversión UNICODE que sea el doble del tamaño del SQL_C_CHAR búfer ANSI. El mecanismo más eficaz es que la aplicación realice la conversión UNICODE y enlace el parámetro como tipo SQL_C_WCHAR. Cuando un parámetro se marca como datos en ejecución y los datos se proporcionan en varias llamadas a SQLPutData, se aumenta un búfer de datos de texto largo. Una manera de evitar el gasto de aumentar este búfer "Put Data" es proporcionar una longitud opcional a través de SQL_DATA_AT_EXEC_LEN(x), donde x es la longitud esperada de bytes. Esto inicializará el tamaño de un búfer PutData interno en x bytes.

Nota

Una manera eficaz de insertar o actualizar datos largos se puede lograr mediante SQLBulkOperations() o SQLSetPos() y establecer los datos largos en SQL_DATA_AT_EXEC. (EXEC_LEN se omite en este caso). Los datos se pueden transmitir en fragmentos mediante una llamada a SQLPutData varias veces, lo que anexará eficazmente los datos a la tabla.

Cuando una aplicación que usa una base de datos Jet 3.5 a través de los controladores de base de datos de escritorio ODBC de Microsoft se actualiza a la versión 4.0, puede producirse una degradación del rendimiento y un mayor tamaño del conjunto de trabajo. Esto se debe a que cuando una versión 3. La base de datos x se abre con el nuevo controlador 4.0, carga Jet 4.0. Cuando Jet 4.0 abre la base de datos y ve que la base de datos es 3. x versión, carga también un controlador ISAM instalable que equivale a cargar el motor Jet 3.5. Para eliminar el rendimiento y la penalización de tamaño, el Jet 3. La base de datos x debe compactarse en una base de datos con formato Jet 4.0. Esto eliminará la carga de dos motores Jet y minimizará la ruta de acceso del código a los datos.

Además, el motor Jet 4.0 es un motor Unicode. Todas las cadenas se almacenan y manipulan en Unicode. Cuando una aplicación ANSI accede a un Jet 3. x base de datos a través del motor Jet 4.0, los datos se convierten de ANSI a Unicode y vuelven a ANSI. Si la base de datos se actualiza al formato 4.0 de la versión, las cadenas se convierten en Unicode, quitando un nivel de conversión de cadena y minimizando la ruta de acceso del código a los datos pasando solo por un motor Jet.