คุณได้อย่างถูกต้องไม่สามารถแปลข้อมูลอักขระจากไคลเอนต์กับเซิร์ฟเวอร์ โดยใช้โปรแกรมควบคุมของ SQL Server ODBC ถ้าไคลเอนต์โค้ดเพจของแตกต่างจากเซิร์ฟเวอร์โค้ดเพจ

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 234748 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

อาการ

เมื่อใช้ MDAC 2.1 หรือรุ่นที่ใหม่กว่าของโปรแกรมควบคุม ODBC เซิร์ฟเวอร์ SQL (รุ่น 3.70.0623 หรือใหม่กว่า) หรือผู้ให้บริการ OLEDB (รุ่น 7.01.0623 หรือใหม่กว่า), บางสถานการณ์ คุณอาจพบการแปลข้อมูลอักขระจากไคลเอนต์โค้ดเพจของหน้ารหัสเซิร์ฟเวอร์ แม้ว่าจะ Autotranslation ถูกปิดใช้งานสำหรับการเชื่อมต่อได้

สาเหตุ

Autotranslation ไม่กลไกเท่านั้นที่สามารถทำให้การแปลงเพรหัส โปรแกรมควบคุม ODBC 7.0 เซิร์ฟเวอร์ SQL และผู้ให้บริการ OLEDB แนะนำลักษณะการทำงานใหม่เมื่อมีการเชื่อมต่อกับ MSDE 1.0, SQL Server 7.0 หรือรุ่นที่ใหม่กว่าอย่างใดอย่างหนึ่ง คำสั่ง SQL ทั้งหมดที่ส่งเป็นเหตุการณ์ในภาษาจะแปลง Unicode บนไคลเอนต์ก่อนที่จะถูกส่งไปยังเซิร์ฟเวอร์ ลักษณะพิเศษการสิ้นสุดนี้จะคล้ายกับข้อ Autotranslation ของข้อมูลทั้งหมดที่ flowing จากไคลเอ็นต์กับเซิร์ฟเวอร์ผ่านเหตุการณ์การภาษา คำนึงถึงการตั้งค่า Autotranslation ปัจจุบันสำหรับการเชื่อมต่อ ซึ่งจะทำให้ไม่เกิดปัญหาใด ๆ ยกเว้นเมื่อพยายามที่จะเก็บข้อมูลไม่แปลอักขระจากโค้ดเพจของอื่นนอกเหนือจากหน้ารหัสของ SQL Server

การหลีกเลี่ยงปัญหา

ไม่เก็บข้อมูล X หน้ารหัสในโค้ดเพจของ Y SQL Server (ตัวอย่างเช่น รหัส 950 ข้อมูลหน้าในเซิร์ฟเวอร์ 1252 หน้ารหัส) ในขณะนี้เป็นไปได้ในบางสถานการณ์กับ SQL Server รุ่นก่อนหน้า นั้นได้ตลอดเวลาถูกไม่สนับสนุน ไปยังเซิร์ฟเวอร์ SQL 1252, anything แต่ 1252 เป็น อักขระที่ไม่ได้ข้อมูลอักขระที่ถูกต้อง ข้อมูลอักขระ Unicode ไม่ใช่จากเพจรหัสอื่นจะไม่สามารถเรียงลำดับอย่างถูกต้อง และในกรณีของข้อมูล (DBCS) ไบต์สอง SQL Server จะไม่รู้จักขอบอักขระอย่างถูกต้อง ซึ่งสามารถเป็นสาเหตุของปัญหาที่สำคัญ เช่นปัญหาอธิบายไว้ในบทความในฐานความรู้ของ Microsoft ต่อไปนี้:
155723INF: truncation SQL Server ของสตริงที่ DBCS
ทางเลือกที่ดีที่สุดสำหรับ SQL Server โค้ดเพจของคือ หน้ารหัสของไคลเอนต์ที่จะสามารถเข้าถึงเซิร์ฟเวอร์

เซิร์ฟเวอร์และไคลเอ็นต์อาจแตกต่างกันของโค้ดเพจ แต่คุณต้องมั่นใจได้ว่า Autotranslation ถูกเปิดใช้งานบนไคลเอนต์ดังนั้นคุณได้รับการแปลที่ถูกต้องของข้อมูลเข้า และออก จากหน้ารหัสของเซิร์ฟเวอร์ในกรณีที่ทั้งหมด

หากเซิร์ฟเวอร์ของคุณต้องจัดเก็บข้อมูลจากหลายหน้ารหัส วิธีแก้ไขปัญหาได้รับการสนับสนุนคือการเก็บข้อมูลในคอลัมน์ Unicode (NCHAR/NVARCHAR/NTEXT)

หากสถานการณ์ของคุณต้องการที่คุณเก็บข้อมูลของเพ X รหัสในโค้ดเพจของ Y SQL Server มีเพียงสองวิธีในการทำเช่นนี้ได้:
  • เก็บข้อมูลในคอลัมน์คอลัมน์ไบนารี (ไบ นารี/VARBINARY/รูป)
  • เขียนโปรแกรมประยุกต์ของคุณจะใช้พื้นที่กระบวนการระยะไกล (rpc) สำหรับคำสั่ง SQL ทั้งหมดที่จัดการกับข้อมูลอักขระ ข้อมูลที่ส่งผ่านเหตุการณ์ RPC ไม่ต้องการแปลงนี้ หมายเหตุว่า ไม่มีสิ่งใดที่โปรแกรมควบคุมหรือ DSN ระดับที่คุณสามารถทำการเปลี่ยนชนิดของเหตุการณ์ที่มีการจัดส่ง การส่งคำสั่งเป็นภาษาหรือเหตุการณ์ RPC ขึ้นทั้งหมด APIs และไวยากรณ์ที่เลือก โดยที่โปรแกรมเมอร์เมื่อโปรแกรมประยุกต์ถูกเขียนไว้

ข้อมูลเพิ่มเติม

Autotranslation กาเครื่อง (นั่นคือ “ดำเนินการแปลงข้อมูลอักขระ"หมายในโปรแกรมประยุกต์ ODBC ที่ใหม่กว่า) แปลงข้อมูลอักขระจากไคลเอนต์โค้ดเพจของหน้ารหัสของเซิร์ฟเวอร์ก่อนที่จะส่งข้อมูลไปยังเซิร์ฟเวอร์ ใช้ Unicode เป็นปานกลางการแปล อย่างไรก็ตาม โปรแกรมควบคุม ODBC เซิร์ฟเวอร์ SQL 3.7 แปลงคำสั่ง SQL ทั้งหมดที่ส่งเป็นเหตุการณ์ภาษาเพื่อ Unicode ก่อนที่จะวางบนสาย ซึ่งมีลักษณะพิเศษที่เหมือนกับ Autotranslation แต่จะไม่โดยสอดคล้องกับการตั้งค่า Autotranslation เช่นกัน ใน contrast อักขระข้อมูล flowing จากเซิร์ฟเวอร์ไป respect ไคลเอนต์ค่าสถานะ Autotranslation หาก Autotranslation ถูกปิดอยู่กับข้อมูลมาถึงที่แอพลิเคชันไคลเอนต์กับอักขระตัวเดียวกับรหัสเป็นข้อมูลที่มีอยู่บนเซิร์ฟเวอร์ ในทำนองเดียวกัน แปลข้อมูลสำหรับไคลเอ็นต์กับเซิร์ฟเวอร์ RPC เหตุการณ์สามารถถูกปิดการใช้งาน โดยการปิด Autotranslation A simple script that demonstrates how this behavior affects language events follows. This example was run from Query Analyzer on a code page 1252 client connecting to a code page 437 server:
-- 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)
Note the following about the preceding example:
  • Even though Autotranslation was off during this batch, the character code 165 (yen in code page 1252) was converted to 157 (yen in code page 437). This is because the ODBC driver converted the SQL string to Unicode before sending it the the server, so the server was able to convert it to the appropriate character for storage in code page 437.
  • When the client ran aSELECTto retrieve the data that had just been stored, the character 157 arrived non-translated at the client (157 shows up as a box "" on a code page 1252 client). This is because the conversion discussed in this article only applies to data sent from the client to the server, not from the server to the client. The data was not translated because the Autotranslation setting is off.

-- 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)
In this case, turning Autotranslation back on had no effect on the translation from the client to the server (that is, the same correct translation from character code 165 to character code 157 happened), but it did have an effect on the data retrieved from the server. Note that when theSELECTstatement is run this time (with Autotranslation on), the yen symbols display correctly in the code page 1252 application because they have been translated from character code 157 back to character code 165 by the Autotranslation mechanism.

You will see this behavior (conversion of language events to Unicode on the client) when using any SQL Server ODBC driver version 3.70 or later and connecting to SQL Server 7.0 or later. It will not occur when using older ODBC drivers, or when using the 3.7 driver to connect to SQL Server 6.5 or earlier. In addition, if you are storing your data in Unicode columns (NCHAR/NVARCHAR/NTEXT) the conversion will not be an issue.
For more information about how character data is represented in SQL Server 2005, click the following article number to view the article in the Microsoft Knowledge Base:
904803Character data is represented incorrectly when the code page of the client computer differs from the code page of the database in SQL Server 2005

คุณสมบัติ

หมายเลขบทความ (Article ID): 234748 - รีวิวครั้งสุดท้าย: 8 มกราคม 2554 - Revision: 3.0
ใช้กับ
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL 2005 Server Workgroup
Keywords: 
kbprb kbmt KB234748 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:234748

ให้ข้อเสนอแนะ

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com