当您添加新的传递job_type
给sys.sp_cdc_add_job @job_type
,
(类型为nvarchar(20)
)
您可以将参数传递为
N'
清理'- 清理
使用前一种语法N'
将参数传递给存储过程是否有任何理由或好处?
当您添加新的传递job_type
给sys.sp_cdc_add_job @job_type
,
(类型为nvarchar(20)
)
您可以将参数传递为
N'
清理'使用前一种语法N'
将参数传递给存储过程是否有任何理由或好处?
仅当字符串包含 unicode 字符时
当传递到存储过程中时,该字符串被隐式转换为 nvarchar。
但是,在 SP 执行之前,它是一个没有 N 前缀的文字 varchar(“字符串常量”)。所以,如果你是日本名字,你需要“N”来使它成为一个“unicode 常量”。请参阅 BOL 中的“常量”,它解释了更多关于,呃,常量...
编辑:受 Andomar 启发的测试...
CREATE PROCEDURE dbo.ZanziBar
@KungFoo nvarchar(1)
AS
SET NOCOUNT ON
SELECT @KungFoo
GO
EXEC dbo.ZanziBar '₠'
EXEC dbo.ZanziBar N'₠'
Windows 中的大多数字符串都是 unicode UCS-16。现在我没有编写 SSMS,但我知道 SSMS 使用 TDS 协议与 SQL Server 对话。因此,符合逻辑的事情是 SSMS 将''
字符串转换为 8 位 TDS 字符串,同时它可以将N''
字符串作为 UCS-16 TDS 字符串发送而无需转换。让我们看看测试中发生了什么:
select '₠', N'₠'
---- ----
? ₠
(1 row(s) affected)
这?
是仅 Unicode 字符的剩余部分,它在 UCS-16 到 8 位的转换中丢失了。
由于 SSMS 不知道存储过程需要什么类型的字符串,我希望它也能''
在存储过程调用中转换字符串。
性能损失应该可以忽略不计,UCS-16 到 UCS-8 和返回非常快。