Problemas de rendimiento del controlador de base de datos de escritorio

Para garantizar la compatibilidad con las aplicaciones ANSI existentes, los tipos de datos 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 tendrá lugar si un parámetro 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 de 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 búfer ANSI de SQL_C_CHAR. 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 longtext. 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 llamando 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 de la versión 4.0, que 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 equivalente a cargar el motor Jet 3.5. Para quitar el rendimiento y la penalización de tamaño, 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 jet 3. x database through the Jet 4.0 engine, the data is converted from ANSI to Unicode and back to ANSI. Si la base de datos se actualiza al formato 4.0 de la versión 4,0, 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.