Problemas de desempenho de driver de banco de dados para desktop

Para garantir a compatibilidade com aplicativos ANSI existentes, os tipos de dados SQL_WCHAR, SQL_WVARCHAR e SQL_WLONGVARCHAR são expostos como SQL_CHAR, SQL_VARCHAR e SQL_LONGVARCHAR para fontes de dados do Microsoft Access 4.0 ou superiores. As fontes de dados não retornam tipos de dados WIDE CHAR, mas os dados ainda devem ser enviados ao Jet no formato Wide Char. É importante entender que a conversão ocorrerá se um parâmetro SQL_C_CHAR ou coluna de resultado estiver associado a um tipo de dados SQL_CHAR em um aplicativo ANSI.

Essa conversão pode ser especialmente ineficiente em termos de memória quando um tipo de SQL_C_CHAR está associado a um parâmetro do tipo LONGVARCHAR. Como o mecanismo Jet 4.0 não consegue transmitir dados de parâmetro LONGTEXT, um buffer de conversão UNICODE deve ser alocado com o dobro do tamanho do buffer ANSI SQL_C_CHAR. O mecanismo mais eficiente é que o aplicativo execute a conversão UNICODE e associe o parâmetro como tipo SQL_C_WCHAR. Quando um parâmetro é marcado como dados em execução e os dados são fornecidos em várias chamadas para SQLPutData, um buffer de dados longtext é cultivado. Uma maneira de evitar a despesa de aumentar esse buffer "Colocar Dados" é fornecer um comprimento opcional por meio de SQL_DATA_AT_EXEC_LEN(x), em que x é o comprimento esperado de bytes. Isso inicializará o tamanho de um buffer PutData interno em x bytes.

Quando um aplicativo que usa um banco de dados Jet 3.5 por meio dos Drivers de Banco de Dados da Área de Trabalho do Microsoft ODBC é atualizado para a versão 4.0, pode ocorrer alguma degradação de desempenho e um maior tamanho do conjunto de trabalho. Isso ocorre porque quando uma versão 3. X database is opened using the new version 4.0 driver, it loads Jet 4.0. Quando o Jet 4.0 abre o banco de dados e vê que o banco de dados é um 3. x versão, ele carrega um driver ISAM instalável que é equivalente ao carregamento do motor Jet 3.5 também. Para remover a penalidade de desempenho e tamanho, o Jet 3. o banco de dados x deve ser compactado em um banco de dados de formato Jet 4.0. Isso eliminará o carregamento de dois mecanismos Jet e minimizará o caminho de código para os dados.

Além disso, o motor Jet 4.0 é um mecanismo Unicode. Todas as cadeias de caracteres são armazenadas e manipuladas no Unicode. Quando um aplicativo ANSI acessa um Jet 3. x banco de dados por meio do mecanismo Jet 4.0, os dados são convertidos de ANSI para Unicode e de volta para ANSI. Se o banco de dados for atualizado para o formato versão 4.0, as cadeias de caracteres serão convertidas em Unicode, removendo um nível de conversão de cadeia de caracteres, bem como minimizando o caminho de código para os dados passando por apenas um mecanismo Jet.