• I feel the question is not trick, just badly written, as it leaves meaning of question up to callous disregard for interpretation. Quoted from the highly current (2008) reference given for the response to the question:

    "

    SQL Server 2008 Books Online (December 2008)

    nchar and nvarchar (Transact-SQL)

    Character data types that are either fixed-length, nchar, or variable-length, nvarchar, Unicode data and use the UNICODE UCS-2 character set.

    nchar [ ( n ) ]

    Fixed-length Unicode character data of n characters. n must be a value from 1 through 4,000. The storage size is two times n bytes. The ISO synonyms for nchar are national char and national character.

    nvarchar [ ( n | max ) ]

    Variable-length Unicode character data. n can be a value from 1 through 4,000. max indicates that the maximum storage size is 2^31-1 bytes. The storage size, in bytes, is two times the number of characters entered + 2 bytes. The data entered can be 0 characters in length. The ISO synonyms for nvarchar are national char varying and national character varying.

    "

    Notice the first sentence in each definition with the period at the end of the sentence. In SQL Server, it means the data in this data type will be Unicoded. Since the terms nchar and nvarchar are SQL Server terms, and not ISO terms, moving that the "n" "stand"s for national is in my view just bad questioning. It may have been derived as a synonym when created, but it strictly indicates Unicoding of the data for SQL Server, regardless of the meaning of the synonym in ISO.

    Of course one could argue that the term "nchar" as a whole means Unicode. However, I would counter that since the only difference between "char" and "nchar" is the "n", that defines the meaning, with the "char" portion defining merely the string type data being encoded, or in this case Unicoded.

    I suppose one could also argue that the question did not explicitly call out "SQL Server". However, since the terms "nchar" and "nvarchar" are not ISO standards or synonyms, but SQL Server terms or data types, and this is primarily a SQL Server site, that the implication that SQL Server is inferred, and not some other system, is nearly by rote. Even if it was another DBMS, it is still not an ISO term.

    (Grin). Yes, I am a little put out that I get a "wrong answer" for choosing Unicode, and I admit that my response here is heavily tongue-in-cheekiness (albeit very correct!).