Question

对于你们中的一些人来说，这可能是非常明显的，但是现在它已经让我烦恼了一段时间。

我有两个在同一个SQL服务器上运行的数据库（2005）。据我所知，他们都有相同的语言/地区属性。两者都将排序规则设置为“Sloveninan_CL_AS”，然后一个存储所有斯洛文尼亚特殊字符（č，ž，š）没有问题，另一个将它们转换为非区域敏感的“匹配”（c，z，s）。 / p>

两个数据库中受区域字符影响的所有字符串都存储在相同类型的字段中（varchar）。

我想知道其他哪些设置会影响这种行为？我可以采取哪些额外步骤来确保在第二个数据库中正确保存特殊字符？

编辑：我能想到的唯一可以证明相关的附加信息是第二个（“故障”）数据库最初使用不同的整理设置创建，并在以后更改，而第一个（可能）是在设置为当前值的情况下创建的。但我认为，由于设置可以更改，这应该不是问题。此外，自更改了排序规则设置以来，服务器已重新启动。

Answer 1

我更喜欢使用NVARCHAR（）数据类型。 NVARCHAR使用Unicode，在本地化方面更加友好。

无论如何，数据库最初是使用不同的排序规则创建的，这绝对是一个重大问题。 在数据库上设置排序规则时，您实际要做的是为新创建的对象设置默认排序规则。查看表格本身。我愿意打赌，他们仍然坚持旧的整理。您可能必须重新创建或更改表和索引才能使新的排序规则生效。

http://msdn.microsoft.com/en-us/library/ms175835.aspx

Answer 2

您是否确实更改了数据库本身的排序规则？不只是专栏？当我在测试数据库上尝试以下脚本并在斯洛文尼亚语和拉丁语之间来回切换数据库校对时，我得到č字符（N前缀版本的不同结果总是有效）

SET NOCOUNT ON

DECLARE @testtable TABLE
(
A VARCHAR(5) COLLATE Slovenian_CI_AS,
B  VARCHAR(5) COLLATE Slovenian_CI_AI
)

INSERT INTO @testtable
VALUES ('čžš','čžš')

INSERT INTO @testtable
VALUES (N'čžš',N'čžš')

SELECT *,CAST(A AS VARBINARY(6)) ,CAST(B AS VARBINARY(6))  
FROM @testtable

Slovenian_CI_AS

A     B                    
----- ----- -------------- --------------
čžš   čžš   0xE89E9A       0xE89E9A
čžš   čžš   0xE89E9A       0xE89E9A

Latin1_General_CI_AS

A     B                    
----- ----- -------------- --------------
cžš   cžš   0x639E9A       0x639E9A
čžš   čžš   0xE89E9A       0xE89E9A

在数据库中存储区域（斯洛文尼亚）字符

2 个答案: