Problemi di prestazioni dei driver di database desktop
Per garantire la compatibilità con le applicazioni ANSI esistenti, i tipi di dati SQL_WCHAR, SQL_WVARCHAR e SQL_WLONGVARCHAR vengono esposti come SQL_CHAR, SQL_VARCHAR e SQL_LONGVARCHAR per le origini dati di Microsoft Access 4.0 o versioni successive. Le origini dati non restituiscono tipi di dati WIDE CHAR, ma i dati devono comunque essere inviati a Jet in formato Wide Char. È importante comprendere che la conversione verrà eseguita se una colonna di SQL_C_CHAR parametro o di risultato è associata a un tipo di dati SQL_CHAR in un'applicazione ANSI.
Questa conversione può essere particolarmente inefficiente in termini di memoria quando un tipo SQL_C_CHAR è associato a un parametro di tipo LONGVARCHAR. Poiché il motore Jet 4.0 non è in grado di trasmettere i dati dei parametri LONGTEXT, è necessario allocare un buffer di conversione UNICODE che corrisponde al doppio delle dimensioni del buffer ANSI SQL_C_CHAR. Il meccanismo più efficiente consiste nell'eseguire la conversione UNICODE e associare il parametro come tipo SQL_C_WCHAR. Quando un parametro viene contrassegnato come data-at-execution e i dati vengono forniti in più chiamate a SQLPutData, viene generato un buffer di dati longtext. Un modo per evitare la crescita di questo buffer "Put Data" consiste nell'fornire una lunghezza facoltativa tramite SQL_DATA_AT_EXEC_LEN(x), dove x è la lunghezza prevista di byte. Verranno inizializzate le dimensioni di un buffer PutData interno in x byte.
Nota
È possibile inserire o aggiornare dati lunghi in modo efficiente usando SQLBulkOperations() o SQLSetPos() e impostando i dati lunghi su SQL_DATA_AT_EXEC. EXEC_LEN viene ignorato in questo caso. I dati possono essere trasmessi in blocchi chiamando PIÙ volte SQLPutData , che aggiungerà effettivamente i dati alla tabella.
Quando un'applicazione che usa un database Jet 3.5 tramite i driver di database desktop Microsoft ODBC viene aggiornata alla versione 4.0, è possibile che si verifichi una riduzione delle prestazioni e che si verifichi un aumento delle dimensioni del set di lavoro. Ciò è dovuto al fatto che quando una versione 3. X database viene aperto usando il nuovo driver versione 4.0, carica Jet 4.0. Quando Jet 4.0 apre il database e rileva che il database è 3. x versione, carica anche un driver ISAM installabile equivalente al caricamento del motore Jet 3.5. Per rimuovere le prestazioni e la riduzione delle dimensioni, jet 3. X database deve essere compattato in un database in formato Jet 4.0. Ciò eliminerà il caricamento di due motori Jet e ridurrà al minimo il percorso del codice per i dati.
Inoltre, il motore Jet 4.0 è un motore Unicode. Tutte le stringhe vengono archiviate e modificate in Unicode. Quando un'applicazione ANSI accede a jet 3. x database tramite il motore Jet 4.0, i dati vengono convertiti da ANSI a Unicode e di nuovo in ANSI. Se il database viene aggiornato al formato 4.0, le stringhe vengono convertite in Unicode, rimuovendo un livello di conversione di stringa e riducendo al minimo il percorso del codice ai dati passando attraverso un solo motore Jet.