Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Bạn một cách chính xác không thể dịch dữ liệu nhân vật từ một khách hàng đến một máy chủ bằng cách sử dụng trình điều khiển SQL Server ODBC nếu khách hàng mã trang khác với tran...

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:234748
TRIỆU CHỨNG
Khi sử dụng MDAC 2,1 hoặc phiên bản sau của trình điều khiển SQL Server ODBC (Phiên bản 3.70.0623 hoặc sau này) hoặc các nhà cung cấp OLEDB (Phiên bản 7.01.0623 hoặc sau này), trong một số trường hợp nào bạn có thể gặp dịch dữ liệu ký tự từ trang mã khách hàng đến trang mã máy chủ, ngay cả khi Autotranslation bị vô hiệu hoá cho kết nối.
NGUYÊN NHÂN
Autotranslation không phải là cơ chế duy nhất mà có thể dẫn đến chuyển đổi trang mã. SQL Server 7.0 ODBC lái xe và nhà cung cấp OLEDB giới thiệu một hành vi mới khi kết nối tới MSDE 1.0, SQL Server 7.0 hoặc phiên bản mới nhất của một trong hai. Tất cả các SQL phát biểu được gửi như là một sự kiện ngôn ngữ được chuyển đổi sang Unicode trên máy khách trước khi được gửi đến máy chủ. Có hiệu lực cuối cùng này là tương tự như một Autotranslation tất cả dữ liệu chảy từ các khách hàng phục vụ thông qua một sự kiện ngôn ngữ, bất kể của hiện tại Autotranslation cài đặt cho kết nối. Điều này sẽ không giới thiệu bất kỳ khó khăn trừ khi cố gắng để lưu trữ dữ liệu ký tự không dịch từ một trang mã khác ngoài trang mã SQL Server.
CÁCH GIẢI QUYẾT KHÁC
Không nên cất mã trang x dữ liệu trong một trang mã Y SQL Server (ví dụ, mã trang 950 data trong một mã trang 1252 server). Trong khi điều này là có thể có trong một số trường hợp với phiên bản trước của SQL Server, nó luôn luôn làkhông được hỗ trợ. Đến một máy chủ SQL 1252, bất cứ điều gì nhưng một 1252 nhân vật là không dữ liệu nhân vật hợp lệ. Non-Unicode ký tự dữ liệu từ một trang khác nhau mã sẽ không được sắp xếp một cách chính xác, và trong trường hợp của kép-byte dữ liệu (DBCS), SQL Server sẽ không công nhận ranh giới của nhân vật một cách chính xác. Điều này có thể gây ra vấn đề quan trọng, chẳng hạn như vấn đề mô tả trong bài viết sau trong cơ sở kiến thức Microsoft:
155723 INF: SQL Server truncation của một chuỗi DBCS
Sự lựa chọn tốt nhất cho SQL Server mã trang là trang mã của các khách hàng sẽ truy cập vào máy chủ.

Các máy chủ và khách hàng có thể khác nhau mã trang, nhưng bạn phải đảm bảo rằng Autotranslation được bật trên máy khách, do đó bạn có được đúng dịch dữ liệu đến và đi từ các máy chủ trang mã trong mọi trường hợp.

Nếu máy chủ của bạn phải lưu trữ dữ liệu từ nhiều mã trang, các giải pháp được hỗ trợ là để lưu trữ dữ liệu trong Unicode cột (NCHAR/NVARCHAR/NTEXT).

Nếu tình hình của bạn đòi hỏi rằng bạn lưu trữ dữ liệu trang x mã trong một trang mã Y SQL Server, có những chỉ có hai cách để làm điều này đáng tin cậy:
  • Lưu trữ dữ liệu trong cột cột nhị phân (BINARY/VARBINARY/hình ảnh).
  • Viết ứng dụng của bạn để sử dụng cuộc gọi thủ tục từ xa (RPCs) cho tất cả các SQL phát biểu mà đối phó với dữ liệu ký tự. Dữ liệu được gửi thông qua một sự kiện RPC là không phải chuyển đổi này. Lưu ý rằng không có gì lúc các trình điều khiển hoặc DSN mức mà bạn có thể làm để thay đổi loại sự kiện được gửi đi được. Cho dù một lệnh được gửi như một ngôn ngữ hoặc sự kiện RPC phụ thuộc hoàn toàn vào các API và cú pháp được lựa chọn bởi các lập trình viên khi ứng dụng được viết.
THÔNG TIN THÊM
Autotranslation (có nghĩa là, các hộp kiểm "Thực hiện dịch cho dữ liệu nhân vật" trong các ứng dụng mới hơn ODBC) chuyển đổi dữ liệu ký tự từ trang mã khách hàng đến trang mã máy chủ trước khi gửi dữ liệu đến máy chủ, sử dụng Unicode như một phương tiện dịch. Tuy nhiên, trình điều khiển SQL Server ODBC 3,7 cũng chuyển đổi tất cả SQL phát biểu được gửi như là một sự kiện ngôn ngữ đến Unicode trước khi đặt chúng trên dây, có hiệu lực mà là tương tự như Autotranslation nhưng không được điều hành bởi các thiết lập Autotranslation. Ngược lại, dữ liệu ký tự chảy từ hệ phục vụ quay lại khách hàng tôn trọng cờ Autotranslation; Nếu Autotranslation đã bị tắt dữ liệu đến lúc khách hàng ứng dụng với các mã số nhân vật tương tự như các dữ liệu đã có trên hệ phục vụ. Tương tự, bản dịch của các dữ liệu cho các sự kiện RPC khách hàng/máy chủ có thể được vô hiệu hóa bằng cách tắt Autotranslation. Một kịch bản đơn giản thể hiện cách hành vi này ảnh hưởng đến các sự kiện ngôn ngữ sau. Ví dụ này chạy từ truy vấn Analyzer trên một mã trang 1252 khách hàng kết nối với một máy chủ 437 trang mã:
-- Turn Autotranslation off here.    USE tempdb    GO    CREATE TABLE t1 (c1 int, c2 char(1))    GO        -- Enter a yen character, using the keystroke ALT-0165.    INSERT INTO t1 VALUES (1, '¥')     SELECT c1, c2, ASCII (c2) FROM t1
c1          c2                       ----------- ---- -----------         1               157                (1 row(s) affected)
Lưu ý sau đây về ví dụ trước:
  • Mặc dù Autotranslation đã tắt trong đợt này, mã ký tự 165 (yên trong mã trang 1252) được cải biến thành 157 (yên trong mã trang 437). Điều này là bởi vì trình điều khiển ODBC chuyển thành chuỗi SQL Unicode trước khi gửi nó các hệ phục vụ, do đó, các máy chủ đã có thể chuyển nó sang ký tự thích hợp cho việc lưu trữ trong mã trang 437.
  • Khi khách hàng chạy một CHỌN truy xuất dữ liệu đã có chỉ được lưu trữ, nhân vật 157 đến không dịch máy khách (157 hiện lên như một hộp "" trên một khách hàng trang 1252 mã). Điều này là do việc chuyển đổi thảo luận trong bài viết này chỉ áp dụng cho dữ liệu được gửi từ các khách hàng đến máy chủ, không phải từ hệ phục vụ cho khách hàng. Dữ liệu không được dịch bởi vì thiết lập Autotranslation là tắt.

-- Turn Autotranslation back on before running the following batch.    INSERT INTO t1 VALUES (2, '¥')    SELECT c1, c2, ASCII (c2) FROM t1
c1          c2                       ----------- ---- -----------         1           ¥    157        2           ¥    157                (2 row(s) affected)
Trong trường hợp này, bật Autotranslation lại đã không có hiệu lực trên bản dịch từ các khách hàng đến các máy chủ đã xảy (có nghĩa là, các bản dịch chính xác cùng một từ mã ký tự 165 để mã ký tự 157 ra), nhưng nó đã có hiệu lực từ ngày các dữ liệu Lấy từ hệ phục vụ. Lưu ý rằng khi các CHỌN tuyên bố được điều hành thời gian này (với Autotranslation ngày), ký hiệu yên hiển thị đúng trong mã trang 1252 ứng dụng bởi vì họ có dịch từ mã ký tự 157 quay lại mã ký tự 165 của cơ chế Autotranslation.

Bạn sẽ thấy hành vi này (chuyển các sự kiện ngôn ngữ sang Unicode trên máy khách) khi sử dụng bất kỳ SQL Server ODBC trình điều khiển phiên bản 3,70 hoặc sau đó và kết nối với SQL Server 7.0 hoặc cao hơn. Nó sẽ không xảy ra khi sử dụng trình điều khiển ODBC cũ hơn, hoặc khi sử dụng trình điều khiển 3,7 để kết nối với SQL Server 6,5 hoặc trước đó. Ngoài ra, nếu bạn đang lưu trữ dữ liệu của bạn trong Unicode cột (NCHAR/NVARCHAR/NTEXT) việc chuyển đổi sẽ không là một vấn đề.
Để biết thêm chi tiết về cách dữ liệu ký tự được đại diện trong SQL Server 2005, nhấp vào số bài viết sau để xem bài viết trong cơ sở kiến thức Microsoft:
904803Dữ liệu ký tự được đại diện không chính xác khi trang mã máy khách khác với trang mã của cơ sở dữ liệu trong SQL Server 2005
CP cs dbcs OemToAnsi AutoAnsiToOem nls charset ký tự đặt SQLExecDirect SQLExecute

Cảnh báo: Bài viết này đã được dịch tự động

Thuộc tính

ID Bài viết: 234748 - Xem lại Lần cuối: 08/21/2011 11:14:00 - Bản sửa đổi: 2.0

Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbprb kbmt KB234748 KbMtvi
Phản hồi