桌面資料庫驅動程式效能問題

為了確保與現有的 ANSI 應用程式相容，SQL_WCHAR、SQL_WVARCHAR和SQL_WLONGVARCHAR數據類型會公開為 Microsoft Access 4.0 或更新版本的數據源SQL_CHAR、SQL_VARCHAR和SQL_LONGVARCHAR。 數據源不會傳回WIDE CHAR資料類型，但數據仍必須以Wide Char形式傳送到 Jet。 請務必瞭解，如果SQL_C_CHAR參數或結果數據行系結至 ANSI 應用程式中的SQL_CHAR數據類型，就會進行轉換。

當SQL_C_CHAR類型系結至 LONGVARCHAR 類型的參數時，此轉換在記憶體方面特別沒有效率。 由於 Jet 4.0 引擎無法串流 LONGTEXT 參數數據，因此必須配置 UNICODE 轉換緩衝區，其大小必須是 ANSI 緩衝區SQL_C_CHAR兩倍的大小。 最有效率的機制是讓應用程式執行 UNICODE 轉換，並將參數係結為類型SQL_C_WCHAR。 當參數標示為數據執行時，並在多個 SQLPutData 呼叫中提供數據時，就會成長長文本數據緩衝區。 避免增加此「放置數據」緩衝區費用的其中一種方法是透過 x SQL_DATA_AT_EXEC_LEN (x) 提供選擇性長度，其中 x 是預期的位元組長度。 這會將內部 PutData 緩衝區的大小初始化為 x 個字節。

注意

您可以使用 SQLBulkOperations () 或 SQLSetPos () ，並將長數據設定為SQL_DATA_AT_EXEC，以有效率的方式插入或更新長數據。 在此情況下會忽略 (EXEC_LEN。) 數據可以多次呼叫 SQLPutData ，以區塊方式串流處理數據，這將會有效地將數據附加至數據表。

當透過 Microsoft ODBC Desktop Database Drivers 使用 Jet 3.5 資料庫的應用程式升級至 4.0 版時，可能會發生一些效能降低和增加的工作集大小。 這是因為第 3 版時。x 資料庫是使用新版本 4.0 驅動程序開啟，它會載入 Jet 4.0。 當 Jet 4.0 開啟資料庫並看到資料庫是 3 時。x 版本，它也會載入相當於載入 Jet 3.5 引擎的可安裝 ISAM 驅動程式。 若要移除效能和大小懲罰，Jet 3。x 資料庫應該壓縮成 Jet 4.0 格式資料庫。 這將會消除載入兩個 Jet 引擎，並將數據的程式代碼路徑降至最低。

此外，Jet 4.0 引擎是 Unicode 引擎。 所有字串都會儲存並操作於 Unicode 中。 ANSI 應用程式存取 Jet 3 時。透過 Jet 4.0 引擎的 x 資料庫，數據會從 ANSI 轉換成 Unicode，然後轉換回 ANSI。 如果資料庫更新為 4.0 版格式，字串會轉換成 Unicode，移除一層字串轉換，並透過一個 Jet 引擎將數據的程式代碼路徑降至最低。