لا يمكن ترجمة بيانات الأحرف من عميل إلى خادم باستخدام برنامج تشغيل SQL Server ODBC إذا كان صفحة رموز العميل يختلف عن شفرة الملقم بشكل صحيح

الأعراض

عند استخدام MDAC 2.1 أو إصدار أحدث من برنامج تشغيل SQL Server ODBC (الإصدار 3.70.0623 أو الإصدار الأحدث) أو موفر OLEDB (الإصدار 7.01.0623 أو ما بعدة)، في بعض الحالات قد تواجه ترجمة بيانات الأحرف من صفحة رموز العميل إلى صفحة التعليمات البرمجية الملقم، حتى عندما يتم تعطيل أوتوترانسليشن للاتصال.

السبب

أوتوترانسليشن غير الآلية الوحيدة التي يمكن أن يؤدي إلى تحويل مخطط الشفرة. برنامج تشغيل SQL Server 7.0 ODBC وموفر OLEDB تقديم الأداء جديد عند الاتصال ب SQL Server 7.0 أو MSDE 1.0 الإصدارات الأحدث من أي. يتم تحويل كافة عبارات SQL التي يتم إرسالها كحدث لغة إلى Unicode على العميل قبل إرسالها إلى الخادم. يماثل التأثير النهائي لهذا أوتوترانسليشن جميع البيانات المتدفقة من العميل إلى الملقم من خلال حدث لغة، بغض النظر عن الإعداد أوتوترانسليشن الحالي للاتصال. هذا لن تسهم بأية صعوبات فيما عدا عند محاولة تخزين البيانات غير ترجمة الأحرف من صفحة التعليمات برمجية بدلاً من SQL Server الصفحة تعليمات برمجية.

الحل البديل

لا تخزن بيانات الصفحة X التعليمات البرمجية في صفحة الترميز اللغوي ص SQL Server (على سبيل المثال، بيانات مخطط شيفرة 950 في خادم 1252 صفحة التعليمات برمجية). إذا كان هذا ممكناً في بعض الحالات مع الإصدارات السابقة من SQL Server، كان دائماً غير معتمد. لخادم SQL 1252، أي شيء ولكن 1252 الحرف غير بيانات صالحة. سوف يتم فرز البيانات حرف Unicode دون من مخطط شفرة مختلفة بشكل صحيح، وفي حالة مزدوجة البايت (DBCS) البيانات SQL Server لن تعترف بحدود الأحرف بشكل صحيح. يمكن أن يسبب هذا مشاكل هامة، مثل المشكلة الموضحة في المقالة التالية في "قاعدة المعارف ل Microsoft":
155723 INF: قطع من سلسلة أحرف DBCS في SQL Server

هو أفضل خيار لصفحة الترميز اللغوي SQL Server صفحة الرموز للعملاء الذين سيصلون في الخادم.

قد يكون الملقم والعميل صفحات التعليمات البرمجية المختلفة، ولكن يجب التأكد من تمكين أوتوترانسليشن على العميل حتى يتسنى الحصول على ترجمة البيانات من صفحة التعليمات البرمجية على الملقم المناسب في جميع الحالات.

إذا كان الملقم الخاص بك يجب تخزين البيانات من عدة صفحات التعليمات البرمجية، حل مدعوم لتخزين البيانات في أعمدة Unicode (NVARCHAR/NCHAR/NTEXT).

إذا كان الموقف يتطلب تخزين بيانات الصفحة X التعليمات البرمجية في صفحة الترميز اللغوي ص SQL Server، هناك طريقتان فقط للقيام بذلك أمانة:
  • تخزين البيانات في الأعمدة الأعمدة الثنائية (ثنائية/أدنى/صورة).
  • كتابة التطبيق الخاص بك لاستخدام "استدعاءات الإجراءات عن بعد" (Rpc) لكافة عبارات SQL التي تتعامل مع بيانات الأحرف. البيانات المرسلة من خلال حدث RPC لا يخضع هذا التحويل. لاحظ أنه ليس هناك مستوى DSN التي يمكنك القيام بها لتغيير أنواع الأحداث التي يتم إرسالها أو برنامج التشغيل. ما إذا كان تم إرسال أمر كاللغة أو الحدث RPC يعتمد كلية على واجهات برمجة التطبيقات وبناء الجملة التي اختارها المبرمج عند كتابة التطبيق.

مزيد من المعلومات

أوتوترانسليشن (أي "إجراء ترجمة بيانات الأحرف" خانات الاختيار في أحدث تطبيقات ODBC) تحويل بيانات الأحرف من صفحة رموز العميل إلى صفحة التعليمات البرمجية على الخادم قبل إرسال البيانات إلى الخادم، استخدام Unicode كوسيلة ترجمة. ومع ذلك، يحول برنامج تشغيل SQL Server ODBC 3.7 أيضا كافة عبارات SQL إرسالها كحدث لغة إلى Unicode قبل وضعها على السلك تأثير يشبه أوتوترانسليشن لكن لا يخضع إعداد أوتوترانسليشن. وفي المقابل، بيانات الأحرف النابعة من الخادم إلى العملاء احترام العلم أوتوترانسليشن؛ إذا تم إيقاف تشغيل أوتوترانسليشن البيانات تصل إلى العميل كان التطبيق باستخدام نفس رموز الأحرف كالبيانات على الملقم. وبالمثل، يمكن تعطيل ترجمة بيانات لإحداث العميل-الملقم RPC بإيقاف تشغيل أوتوترانسلاتيون. يتبع برنامج نصي بسيط يوضح كيف يؤثر هذا السلوك على أحداث اللغة. تم تشغيل هذا المثال من "محلل استعلام" على عميل 1252 صفحة التعليمات برمجية الاتصال بملقم 437 صفحة التعليمات برمجية:
-- 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)
لاحظ التالي حول المثال السابق:
  • حتى ولو كان أوتوترانسليشن إيقاف خلال هذه المجموعة، تم تحويل رمز الحرف 165 (ين في صفحة الترميز اللغوي 1252) إلى 157 (ين في صفحة الرموز 437). هذا بسبب برنامج تشغيل ODBC تحويل سلسلة SQL إلى Unicode قبل إرساله الخادم، ذلك الملقم قادراً على تحويلها إلى أحرف مناسبة للتخزين في صفحة الرموز 437.
  • عند تشغيل العميل حدد لاسترداد البيانات التي تم تخزينها فقط، الحرف 157 وصلت ترجمة غير العميل (157 كما يظهر مربع "" على عميل 1252 صفحة التعليمات برمجية). هذا بسبب عملية التحويل التي تمت مناقشتها في هذه المقالة ينطبق فقط على البيانات المرسلة من العميل إلى الملقم، وليس من الخادم إلى العميل. لم تترجم البيانات لأنه تم إيقاف تشغيل إعداد أوتوترانسليشن.

-- 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)
في هذه الحالة، تشغيل أوتوترانسليشن لدى أي تأثير على الترجمة من العميل إلى الملقم (أي حدث نفس الترجمة الصحيحة من رمز الحرف 165 إلى رمز الحرف 157)، لكن لديها تأثير على البيانات التي تم استردادها من الملقم. لاحظ أن عند تشغيل عبارة SELECT هذه المرة (مع أوتوترانسليشن على)، الرموز الين تعرض بشكل صحيح في التطبيق 1252 صفحة التعليمات البرمجية نظراً لأنها قد ترجمت من رمز الحرف 157 إلى رمز الحرف 165 إليه أوتوترانسليشن.

ستشاهد هذا السلوك (تحويل الأحداث اللغة إلى Unicode على العميل) عند استخدام أي SQL Server ODBC إصدار برنامج التشغيل 3.70 أو أحدث والاتصال ل SQL Server 7.0 أو أحدث. لن يحدث عند استخدام برامج تشغيل ODBC القديمة، أو عند استخدام برنامج تشغيل 3.7 للاتصال ب SQL Server 6.5 أو إصدار سابق. وبالإضافة إلى ذلك، إذا تم تخزين البيانات في أعمدة Unicode (NCHAR/NVARCHAR/NTEXT) التحويل لن تكون مشكلة.
لمزيد من المعلومات حول كيفية تمثيل بيانات الأحرف في SQL Server 2005، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":

904803 بيانات الأحرف يتم تمثيل غير صحيح عند صفحة الرموز للكمبيوتر العميل يختلف شفرة قاعدة البيانات في SQL Server 2005

خصائص

رقم الموضوع: 234748 - آخر مراجعة: 09‏/01‏/2017 - المراجعة: 1

تعليقات