Masalah Performa Driver Database Desktop

  • Artikel

Untuk memastikan kompatibilitas dengan aplikasi ANSI yang ada, jenis data SQL_WCHAR, SQL_WVARCHAR, dan SQL_WLONGVARCHAR diekspos sebagai SQL_CHAR, SQL_VARCHAR, dan SQL_LONGVARCHAR untuk sumber data Microsoft Access 4.0 atau yang lebih tinggi. Sumber data tidak mengembalikan jenis data WIDE CHAR tetapi data masih harus dikirim ke Jet dalam bentuk Wide Char. Penting untuk dipahami bahwa konversi akan terjadi jika parameter SQL_C_CHAR atau kolom hasil terikat ke jenis data SQL_CHAR dalam aplikasi ANSI.

Konversi ini dapat sangat tidak efisien dalam hal memori ketika jenis SQL_C_CHAR terikat ke parameter jenis LONGVARCHAR. Karena mesin Jet 4.0 tidak dapat mengalirkan data parameter LONGTEXT, buffer konversi UNICODE harus dialokasikan yang dua kali ukuran SQL_C_CHAR buffer ANSI. Mekanisme yang paling efisien adalah agar aplikasi melakukan konversi UNICODE dan mengikat parameter sebagai jenis SQL_C_WCHAR. Ketika parameter ditandai sebagai data-at-execution dan data disediakan dalam beberapa panggilan ke SQLPutData, buffer data longtext ditanam. Salah satu cara untuk menghindari pengeluaran menumbuhkan buffer "Put Data" ini adalah dengan memasok panjang opsional melalui SQL_DATA_AT_EXEC_LEN(x), di mana x adalah panjang byte yang diharapkan. Ini akan menginisialisasi ukuran buffer PutData internal ke x byte.

Catatan

Cara efisien untuk menyisipkan atau memperbarui data panjang dapat dicapai menggunakan SQLBulkOperations() atau SQLSetPos() dan mengatur data panjang ke SQL_DATA_AT_EXEC. (EXEC_LEN diabaikan dalam kasus ini.) Data dapat dialirkan dalam gugus dengan memanggil SQLPutData beberapa kali, yang secara efektif akan menambahkan data ke tabel.

Ketika aplikasi yang menggunakan database Jet 3.5 melalui Driver Database Desktop Microsoft ODBC ditingkatkan ke versi 4.0, beberapa penurunan performa dan peningkatan ukuran set kerja dapat terjadi. Ini karena ketika versi 3. database x dibuka menggunakan driver versi 4.0 baru, memuat Jet 4.0. Ketika Jet 4.0 membuka database dan melihat bahwa database adalah 3. versi x , ia memuat driver ISAM yang dapat diinstal yang setara dengan memuat mesin Jet 3.5 juga. Untuk menghapus penalti performa dan ukuran, Jet 3. database x harus dikompresi ke dalam database format Jet 4.0. Ini akan menghilangkan pemuatan dua mesin Jet dan meminimalkan jalur kode ke data.

Selain itu, mesin Jet 4.0 adalah mesin Unicode. Semua string disimpan dan dimanipulasi di Unicode. Ketika aplikasi ANSI mengakses Jet 3. x database melalui mesin Jet 4.0, data dikonversi dari ANSI ke Unicode dan kembali ke ANSI. Jika database diperbarui ke format versi 4.0, string dikonversi ke Unicode, menghapus satu tingkat konversi string serta meminimalkan jalur kode ke data dengan hanya melalui satu mesin Jet.