First time I ran across a query like the one below,

SELECT CustomerID, CompanyName FROM Customers WHERE CustomerID = N'CAMBR'

I asked myself, why is there an ‘N’ before ‘CAMBR’. Well, the ‘N’ actually designates unicode. If your query contains a field that can only be represented by 2 byte characters (i.e. Asian or accented characters), you need to use the N before the value or SQL Server will replace the characters with garbage (usually question marks). Below is another example, USE Northwind

SELECT CompanyName, ContactName, Phone, Fax
FROM Customers WHERE CompanyName LIKE N'%snabbk'p'
ORDER BY CompanyName ASC, ContactName ASC

For most cases, you should avoid using unicode. Unicode makes your database larger and slower. Also in a nvarchar field you only can store 4000 chars instead of 8000 in a “normal” varchar field. If you have in index on a nchar or nvarchar field it will take twice of the size therefore reducing the performance. I spend a good amount of time working with the Japanese character set and have run across some of these issues. If you do use Unicode, all Unicode is not the same. The Win32 API, Java, ODBC/OLEDB, etc all use UCS-2/UTF-16 as their representation of Unicode (UCS-2 encodes Unicode using 16 bits per character instead of the variable 8-24 bits used by UTF-8). But, Oracle, among others, use UTF-8, which is a multi-byte representation of Unicode. So, in UTF-8, typical ASCII codes are single byte, and double-byte is only used if a Unicode character is interjected.