字元資料的自動轉譯
字元資料 (例如，利用 SQL_C_CHAR 宣告的 ANSI 字元變數，或使用 char、varchar 或 text 資料類型儲存在 SQL Server 中的資料) 僅能代表有限的字元數目。每個字元使用一個位元組儲存的字元資料僅能代表 256 個字元。儲存在 SQL_C_CHAR 變數中的值會使用用戶端電腦的 ANSI 字碼頁 (ACP) 解譯。在伺服器上使用 char、varchar 或 text 資料類型儲存的值會利用伺服器的 ACP 進行評估。
如果伺服器和用戶端都有相同的 ACP，則在解譯儲存在 SQL_C_CHAR、char、varchar 或 text 物件中的值時，不會有任何問題。如果伺服器與用戶端的 ACP 不同，當 ACP 用於 char、varchar 或 text 資料行、變數或參數時，用戶端中的 SQL_C_CHAR 資料在伺服器上可能會解譯為不同的字元。例如，包含值 0xA5 的字元位元組在使用字碼頁 437 的電腦上會解譯為字元 Ñ，而在執行字碼頁 1252 的電腦上則會解譯為 Yen Sign (¥)。
Unicode 資料的每個字元會使用兩個位元組儲存。Unicode 規格包含所有擴充字元，因此所有電腦都會以相同方式解譯所有 Unicode 字元。
SQL Server Native Client ODBC 驅動程式的 AutoTranslate 功能會嘗試將在字碼頁不同之用戶端與伺服器之間移動字元資料的問題降至最低。AutoTranslate 可以在 SQLDriverConnect 的連接字串中、SQLConfigDataSource 的組態字串中設定，也可以在使用 ODBC 管理員設定 SQL Server Native Client ODBC 驅動程式的資料來源時設定。
當 AutoTranslate 設定為 "no" 時，不會轉換在用戶端的 SQL_C_CHAR 變數與 SQL Server 資料庫的 char、varchar 或 text 資料行、變數或參數之間移動的資料。如果資料包含擴充字元，而且用戶端電腦和伺服器電腦的字碼頁不同，則位元模式在兩部電腦上的解譯方式可能會不同。如果兩部電腦的字碼頁相同，資料將會以相同的方式解譯。
當 AutoTranslate 設定為 "yes" 時，SQL Server Native Client ODBC 驅動程式會使用 Unicode 轉換在用戶端的 SQL_C_CHAR 變數與 SQL Server 資料庫的 char、varchar 或 text 資料行、變數或參數之間移動的資料。
將資料從用戶端上的 SQL_C_CHAR 變數傳送到 SQL Server 資料庫中的 char、varchar 或 text 資料行、變數或參數時，ODBC 驅動程式會使用用戶端的 ACP，先從 SQL_C_CHAR 轉換為 Unicode，然後再使用伺服器的 ACP，從 Unicode 轉回字元。
將資料從 SQL Server 資料庫中的 char、varchar 或 text 資料行、變數或參數傳送到用戶端上的 SQL_C_CHAR 變數時，SQL Server Native Client ODBC 驅動程式會使用伺服器的 ACP，先從字元轉換為 Unicode，然後再使用用戶端的 ACP，從 Unicode 轉回 SQL_C_CHAR。
由於這些所有轉換都是透過在用戶端上執行的 SQL Server Native Client ODBC 驅動程式完成，因此，伺服器 ACP 必須是安裝在用戶端電腦上的其中一個字碼頁。
透過 Unicode 進行字元轉換可確保正確轉換同時存在兩個字碼頁上的所有字元。但是，如果字元存在於其中一個字碼頁，但不存在於另一個字碼頁，則無法在目標字碼頁中表示字元。例如，字碼頁 1252 擁有註冊商標符號 (®)，而字碼頁 437 則沒有。
AutoTranslate 設定在進行下列轉換時沒有作用：
在字元 SQL_C_CHAR 用戶端變數與 SQL Server 資料庫中的 Unicode nchar、nvarchar 或 ntext 資料行、變數或參數之間移動資料。
在 Unicode SQL_C_WCHAR 用戶端變數與 SQL Server 資料庫中的字元 char、varchar 或 text 資料行、變數或參數之間移動資料。
從字元移到 Unicode 時，永遠必須轉換資料。