字元資料，例如使用 char、Varchar 或 text 資料類型，以SQL_C_CHAR宣告的 ANSI 字元變數，或使用char、Varchar或text資料類型儲存在SQL Server的資料，只能代表有限的字元數。 每個字元使用一個位元組儲存的字元資料僅能代表 256 個字元。 儲存在 SQL_C_CHAR 變數中的值會使用用戶端電腦的 ANSI 字碼頁 (ACP) 解譯。 使用伺服器的 ACP 評估伺服器上使用 char、 Varchar或 text 資料類型儲存的值。
如果伺服器和用戶端都有相同的 ACP，則解譯儲存在 SQL_C_CHAR、 char、 Varchar或 text 物件中的值時沒有任何問題。 如果伺服器和用戶端有不同的 ACL，則如果用戶端在 char、 Varchar或 text 資料行、變數或參數中使用，則用戶端SQL_C_CHAR資料可能會解譯為伺服器上的不同字元。 例如，包含值0xA5的字元位元組會解譯為字元 ？？ 使用字碼頁 437 的電腦上，並解譯為 (？？在執行字碼頁 1252 的電腦上) 。
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 來轉換在用戶端和char、Varchar或text資料行、變數或參數SQL Server資料庫中SQL_C_CHAR變數之間移動的資料：
當資料從用戶端上的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用戶端變數與 Unicode Nchar、Nvarchar或Ntext資料行、變數或參數之間移動資料SQL Server資料庫中。
在 Unicode SQL_C_WCHAR用戶端變數和字元char、Varchar或text資料行、變數或參數之間移動資料SQL Server資料庫中。
從字元移到 Unicode 時，永遠必須轉換資料。