為了確保與現有的 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 的多個呼叫中提供數據時，就會成長長文本數據緩衝區。 避免增加這個「放置數據」緩衝區費用的其中一種方法是透過 SQL_DATA_AT_EXEC_LEN（x） 提供選擇性長度，其中 x 是預期的位元組長度。 這會將內部 PutData 緩衝區的大小初始化為 x 個字節。
備註
您可以使用 SQLBulkOperations（） 或 SQLSetPos（） 來完成插入或更新長數據的有效方式，並將長數據設定為SQL_DATA_AT_EXEC。 （在此情況下會忽略EXEC_LEN。數據可以藉由呼叫 SQLPutData 多次以區塊串流處理，這會有效地將數據附加至數據表。
當透過 Microsoft ODBC 桌面資料庫驅動程式使用 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 時。x 資料庫透過 Jet 4.0 引擎，數據會從 ANSI 轉換成 Unicode，然後轉換回 ANSI。 如果資料庫更新為 4.0 版格式，字串會轉換成 Unicode，移除一層字串轉換，並透過只經過一個 Jet 引擎，將數據的程式代碼路徑降到最低。