سلوك SQL غريب، لماذا لا يُرجع هذا الاستعلام شيئًا؟

Question

افترض أن هناك جدولًا باسم "myTable" يحتوي على ثلاثة أعمدة:

{**ID**(PK, int, not null), 
 **X**(PK, int, not null), 
 **Name**(nvarchar(256), not null)}.

اجعل {4, 1, аккаунт} سجلاً على الطاولة.

select * from myTable as t 
    where t.ID=4  
    AND t.X = 1 
    AND (     t.Name = N'аккаунт'  )

select * from myTable as t 
    where t.ID=4  
    AND t.X = 1 
    AND (  t.Name LIKE N'%аккаунт%'  )

الاستعلام الأول يعيد السجل، لكن الثاني لا؟لماذا؟

الأنظمة التي تواجه هذه المشكلات:

*نظام التشغيل Windows XP - Professional - الإصدار 2002 - SP3
ترتيب الخادم: Latin1_جنرال_CI_AS
إصدار: 9.00.3073.00
مستوى: SP2
الإصدار: إصدار المطور

قطع الترتيب: SQL_Latin1_جنرال_CP1_CI_AS
إصدار: 9.00.3054.00
مستوى: SP2
الإصدار: إصدار المؤسسة

نتائج:

SELECT SERVERPROPERTY('SQLCharSetName')
iso_1

Using OSQL.exe
0x30043A043A04300443043D04420400000000000000000000000000000000
0x3F3F3F3F3F3F3F0000000000000000000000000000000000000000000000
0x253F3F3F3F3F3F3F25000000000000000000000000000000000000000000

SELECT CAST(name AS BINARY),
       CAST(N'аккаунт' AS BINARY),
       CAST(N'%аккаунт%' AS BINARY)
FROM   myTable t
WHERE  t.ID = 4  
       AND t.X = 1

CAST(name AS BINARY) 
0x30043A043A04300443043D04420400000000000000000000000000000000  
CAST(N'аккаунт' AS BINARY)
0x3F3F3F3F3F3F3F0000000000000000000000000000000000000000000000  
CAST(N'%аккаунт%' AS BINARY)
0x253F3F3F3F3F3F3F25000000000000000000000000000000000000000000

Answer 1

حسنا، بعد الكثير من البحث، وجدت أنه هو في الواقع مشكلة الاطلاع على الإصدارات التالية من SQL Server 2005:

ويندوز XP - المهنية - صفحة 2002 - SP3
الإصدار: 9.00.3073.00
المستوى: SP2
الطبعة: الطبعة المطور

الإصدار: 9.00.3054.00
المستوى: SP2
الطبعة: الطبعة المؤسسة

و.. قد يكون إصدارات أخرى كذلك.

وFIX: الترقية إلى SP3

Answer 2

هل يمكنك من فضلك نشر نتيجة الاستعلام التالي:

SELECT CAST(name AS BINARY),
       CAST(N'аккаунт' AS BINARY),
       CAST(N'%аккаунт%' AS BINARY)
FROM   myTable t
WHERE  t.ID = 4  
       AND t.X = 1

وهذا سوف يساعد على تضييق المشكلة.

تحديث:

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

يتم تحويل القيم الحرفية السيريلية من ثوابت السلسلة إلى علامات الاستفهام (0x3F).

لسوء الحظ، لا أستطيع إعادة إنتاج هذا السلوك مع Management Studio على خادم الاختبار الخاص بي.

أعتقد أن هناك مشكلة ما OS الإعدادات، حيث أن الأحرف السيريلية على الأرجح لا تصل إليها SQL Server.

هل يمكنك الإجابة على ثلاثة أسئلة أخرى:

1. ماذا OS هل تستخدم (الإصدار، اللغة، MUI لو اي)

   • ماذا يعود هذا الاستعلام:

     حدد خاصية الخادم ("SQLCharSetName")

   • اتصل بالخادم الخاص بك باستخدام osql.exe وإصدار هذا الاستعلام:

     حدد CAST (الاسم ثنائي) ، يلقي (n'аакауائية "كما ثنائي) ، يلقي (n '٪ акаунт ٪' كما ثنائي) من mytable t حيث t.id = 4
     و TX = 1 اذهب

   ماذا يعود يجري في osql.exe?

Answer 3

وكل الاستفسارات تعود إلى نفس النتيجة بالنسبة لي.

select * from myTable as t
where t.ID=4
AND t.X = 1
AND (t.Name = N'аккаунт')

وإرجاع:

ID          X           Name
----------- ----------- ------------
4           1           аккаунт

و

select * from myTable as t
where t.ID=4
AND t.X = 1
AND (t.Name LIKE N'%аккаунт%')

وإرجاع:

ID          X           Name
----------- ----------- ------------
4           1           аккаунт

و(1 الصف (الصفوف) تتأثر)

وبلدي إصدار SQL Server هو:

Microsoft SQL Server 2005 - 9.00.3077.00 (Intel X86) 
    Dec 17 2008 15:19:45 
    Copyright (c) 1988-2005 Microsoft Corporation
    Express Edition on Windows NT 5.1 (Build 2600: Service Pack 3)

وتعيين بلدي الترتيب إلى: SQL_Latin1_General_CP1_CI_AS

ونتائجي لQuassnoi: 0x30043A043A04300443043D04420400000000000000000000000000000000 0x30043A043A04300443043D04420400000000000000000000000000000000 0x250030043A043A04300443043D0442042500000000000000000000000000

و(1 الصف (الصفوف) تتأثر)