Reason for using hexadecimal in NCHAR()?

I found this in some source code today:

``````        SELECT
@Error = ERROR_NUMBER (),
@ErrorMsg = N'An Error occured while populating the TABLE ' + @DestinationTableName +
N' with data. Error Code: ' + CAST ( @Error AS nvarchar(20) ) +
N', Error Description: "' + ERROR_MESSAGE () + N'".'
+ NCHAR(0X0D) + NCHAR(0X0A) + NCHAR(0X0D) + NCHAR(0X0A),
@ErrorSeverity = ERROR_SEVERITY (),
@ErrorState = ERROR_STATE () ;
``````

It looks like the error message string is adding two line feeds after the description. 0X0D is 13 and 0X0A is 10.

Normally what I've done is NCHAR(13) + NCHAR(10)...

-

Yes, there is the obvious readability reason. For programmers, decimal numbers are meaningless. What the heck is `3221225477`? But `0xc0000005` you recognize it immediately. `2147500037`? Rings no bell, but `0x80004005` uberwellknown. These are value that carry meaning, you recognize them at a glance after seeing them every day in the debugger... It becomes second nature.

And no, I'm not kidding nor being sarcastic. I'm very serious. I would had also use 0x0D and 0x0A. If I see 13 I would have to think what value that is.

-

Like you said in your question, those values are equivalent and therefore no there is no reason or difference. It's just the used base (hexadecimal [base 16] vs. decimal [base 10]).

Here's proof they are equal:

``````if nchar(13) = nchar(0x0D)
begin
print 'nchar(13) is equal to nchar(0x0D)';
end
``````

So, to answer your question: no, there is no reason to use hexadecimal over decimal values. Traditionally with bitmaps and bitwise operations it is much easier to do visual bit math with hex, but that clearly isn't the driving force behind the original developer's intent with this code.

Also see BOL's reference on NCHAR:

Syntax

``````NCHAR ( integer_expression )
``````

integer_expression

When the collation of the database does not contain the supplementary character (SC) flag, this is a positive whole number from 0 through 65535 (0 through 0xFFFF). If a value outside this range is specified, NULL is returned. For more information about supplementary characters, see Collation and Unicode Support.

When the collation of the database supports the supplementary character (SC) flag, this is a positive whole number from 0 through 1114111 (0 through 0x10FFFF). If a value outside this range is specified, NULL is returned.

-