views:

330

answers:

2

When you add pass a new job_type to sys.sp_cdc_add_job @job_type,
(which is of type nvarchar(20))

You can pass the argument as either

  • N'cleanup'
  • cleanup

Are there any reasons or benefits to use the former syntax using N' to pass the argument to stored procedures?

+4  A: 

Only if the string contains unicode characters

The string is implictly converted to nvarchar when the passed into the stored proc.

However, before SP execution, it's a literal varchar ("character string constant") without N prefix. So, if you Japanese names, you'll need "N" to make it a "unicode constant". See "constants" in BOL which explains more about, er, constants...

Edit: A test of this inspired by Andomar...

CREATE PROCEDURE dbo.ZanziBar
   @KungFoo nvarchar(1)
AS
SET NOCOUNT ON
SELECT @KungFoo
GO

EXEC dbo.ZanziBar '₠'

EXEC dbo.ZanziBar N'₠'
gbn
Both Windows strings and nvarchars are stored in UCS-16. So I think it's unlikely that a *string is implictly converted to nvarchar*. It's the other way around: a non-N-prefixed string is converted to some 8-bit encoding, while an N-prefixed string is transmitted "as is".
Andomar
@Andomar: it is converted when passed into the stored proc. The calling batch parses it according to the "N"
gbn
+5  A: 

Most strings in Windows are unicode UCS-16. Now I didn't write SSMS, but I know SSMS talks to SQL Server using the TDS protocol. So the logical thing to expect is that SSMS converts '' strings to an 8-bit TDS string, while it can send N'' strings as a UCS-16 TDS string without conversion. Let's see what happens in a test:

select '₠', N'₠'
---- ----
?    ₠

(1 row(s) affected)

The ? is what's left of the Unicode-only character, it got lost in the UCS-16 to 8-bit translation.

Since SSMS does not know what type of string a stored procedure expects, I expect it to convert a '' string in a stored procedure call as well.

The performance penalty should be negligible, UCS-16 to UCS-8 and back is very fast.

Andomar