Problemas de desempenho do driver de banco de dados de área de trabalho
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 superior. As fontes de dados não retornam tipos de dados WIDE CHAR, mas os dados ainda devem ser enviados ao Jet na forma 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 de texto longo é aumentado. 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.
Observação
Uma maneira eficiente de inserir ou atualizar dados longos pode ser realizada usando SQLBulkOperations() ou SQLSetPos() e definindo os dados longos como SQL_DATA_AT_EXEC. (EXEC_LEN é ignorado nesse caso.) Os dados podem ser transmitidos em partes chamando SQLPutData várias vezes, o que efetivamente acrescentará os dados à tabela.
Quando um aplicativo que usa um banco de dados Jet 3.5 por meio dos Drivers de Banco de Dados da Área de Trabalho ODBC da Microsoft é atualizado para a versão 4.0, pode ocorrer alguma degradação de desempenho e um tamanho maior 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 version, ele carrega um driver ISAM instalável que é equivalente a carregar o 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 do 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 database through the Jet 4.0 engine, the data is converted from ANSI to Unicode and back to 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.