In the condition with the Chinese can not be queried, because the field sender_su_name is nvarchar type, need to precede a n
SELECT * from [test]. [dbo]. [Ship_user_email] WHERE [sender_su_name]=n ' reward '
Why take N as explained below:
Using Unicode data
The Unicode standard defines a single coding scheme for most of the characters widely used in the global business world. All computers are consistently translated into characters using a bit pattern in a single Unicode standard Unicode data. This ensures that the same bit pattern is always converted to the same character on all computers. Data can be transferred freely from one database or computer to another without worrying about whether the receiving system translates bit patterns incorrectly.
One of the problems with data types that encode each character with one byte is that this data type can only represent 256 different characters. This forces the use of multiple coding specifications (or code pages) for different alphabets (for example, the relatively small European alphabet). It is also impossible to handle an alphabet with thousands of characters, such as kanji or Korean text.
Each Microsoft? SQL Server? Collations have a code page that defines a bit pattern for each character in char, varchar, and text values. You can assign different code pages for individual columns and character constants. The client computer interprets the character bit pattern using the code page that is associated with the operating system locale. There are a number of different code pages. Some characters appear on some code pages, but do not appear on other code pages. Some characters are defined in one bit pattern on some code pages, while others are defined with a second bit pattern on other code pages. When you design an international system that has to deal with different languages, it becomes difficult to pick up code pages for all computers to meet the language needs of different countries. It is also difficult to make sure that each computer interacts correctly with a system that uses a different code page.
The Unicode specification solves this problem by encoding each character with two bytes. Converting a single specification of the most common business language has enough 2-byte patterns (65,536). Because all Unicode systems consistently use the same bit pattern to represent all characters, there will be no problem converting characters incorrectly when you go from one system to another. By using Unicode data types throughout your system, you can minimize character conversion problems.
In Microsoft SQL Server, the following data types support Unicode data:
NChar
nvarchar
ntext
Describes the prefix n for these data types from the national (Unicode) data type in the SQL-92 standard.
nchar, nvarchar, and ntext are used in the same way as char, varchar, and text, but differ in the following ways:
Unicode supports a larger range of characters.
The space required to store Unicode characters is greater.
The nchar and nvarchar columns can have up to 4,000 characters, unlike char and varchar characters, which can be as many as 8,000 characters.
Unicode constants are specified by using N: N ' A Unicode string '.
All Unicode data uses the same Unicode code page. Collations do not control the code pages that are used for Unicode columns, only those that control comparison rules and are case-sensitive.
This article is from the "Holy" blog, make sure to keep this source http://holy2010.blog.51cto.com/1086044/1843094
The condition field in Microsoft SQL Server is of type nvarchar, the condition has the reason of Chinese can't query and how to deal with it