Início / dba / Perguntas / 207722
Accepted
Yaroslav
Asked: 2018-05-25 02:48:19 +0800 CST

N'Șc' considerada chave duplicada de N'C' usando o agrupamento Latin1_General_CI_AS

  • 772

Eu tenho uma tabela com uma chave exclusiva que inclui uma NVARCHAR(50)coluna (correta ou não, mas existe). Então, ao tentar inserir Școu C(não importa a ordem da inserção) ele quebra na 2ª inserção devido a problemas de agrupamento. Aqui está o erro:

(1 linha(s) afetada) Msg 2601, Level 14, State 1, Line 16 Não é possível inserir linha de chave duplicada no objeto 'dbo.testT' com índice exclusivo 'IX_TestT'. O valor da chave duplicada é (C).

Selecione retornos:

insira a descrição da imagem aqui

O agrupamento padrão do banco de dados é Latin1_General_CI_AS. Passei algum tempo procurando como resolver, sem alterar muito a estrutura já existente, mas não consigo encontrar uma maneira de começar a funcionar. Tentei diferentes agrupamentos e combinações, tudo falha. Leia ( aqui e aqui ) sobre expansões de personagens e assim por diante, ainda travado. Aqui está um código de exemplo que estou usando para replicar o problema, sinta-se à vontade para modificar e recomendar qualquer coisa que possa ajudar a resolver isso.

CREATE TABLE testT (
    [Default_Collation]     [NVARCHAR] (50) COLLATE DATABASE_DEFAULT,
    [Latin1_General_CI_AS]  [NVARCHAR] (50) COLLATE Latin1_General_CI_AS,
    [Latin1_General_CI_AI]  [NVARCHAR] (50) COLLATE Latin1_General_CI_AI,
    [SQL_Collation]         [NVARCHAR] (50) COLLATE SQL_Latin1_General_CP1_CI_AS);
CREATE UNIQUE CLUSTERED INDEX [IX_TestT] ON [dbo].[testT] ([Default_Collation])
ON [PRIMARY]
GO

INSERT INTO testT
SELECT  N'Șc',  --COLLATE Latin1_General_CI_AS
        N'Șc',  --COLLATE Latin1_General_CI_AS
        N'Șc',  --COLLATE Latin1_General_CI_AS
        N'Șc'   --COLLATE Latin1_General_CI_AS

INSERT INTO testT
SELECT  N'C'    --COLLATE Latin1_General_CI_AS 
        ,N'C'   --COLLATE Latin1_General_CI_AS
        ,N'C'   --COLLATE Latin1_General_CI_AS
        ,N'C'   --COLLATE SQL_Latin1_General_CP1_CI_AS

SELECT * FROM testT;

DROP TABLE testT;
sql-server t-sql

1 respostas

  1. Best Answer

    O problema é que o antigo SQL Server Collations (ou seja, aqueles com nomes começando com SQL_) e as duas primeiras versões do Windows Collations (a 80série que veio com o SQL Server 2000 e não tem um número de versão no nome, e a 90série que veio com o SQL Server 2005) estão faltando os pesos de classificação para muitos caracteres. Isso foi corrigido principalmente a partir da 100série Collations que acompanha o SQL Server 2008.

    Como você pode ver nos exemplos abaixo, o Șcaractere corresponde a uma string vazia ao usar agrupamentos não binários, versão 80 ou 90 (e agrupamentos do SQL Server), pois ambos têm o mesmo peso de classificação: 0. Nada. Nada. Isso significa que ao comparar N'Șc'com N'C'(usando pré-série 100 Collations), você está realmente comparando N'c'com N'C'(teste nº 1):

    SELECT 1 WHERE N'Șc' = N'C' COLLATE Latin1_General_CS_AS;
-- no result (due to "c" and "C" being different case)

SELECT 2 WHERE N'Ș' = N'' COLLATE SQL_Latin1_General_CP1_CI_AS;
SELECT 3 WHERE N'Ș' = N'' COLLATE Latin1_General_CI_AS;

SELECT 4 WHERE N'Ș' = N'' COLLATE Latin1_General_BIN2;
-- no result (due to "Ș" still being a code point and empty string has no code points)

SELECT 5 WHERE N'Ș' = N'' COLLATE Latin1_General_100_CI_AS;
-- no result (due to "Ș" finally having a sort weight in 100 series Collations)

SELECT 6 WHERE N'Ș' = N'' COLLATE Chinese_PRC_CI_AI;
SELECT 7 WHERE N'Ș' = N'' COLLATE Chinese_PRC_90_CI_AI;

SELECT 8 WHERE N'Ș' = N'' COLLATE Indic_General_90_CI_AI;
SELECT 9 WHERE N'Ș' = N'' COLLATE Indic_General_100_CI_AI;
-- no result (due to "Ș" finally having a sort weight in 100 series Collations)

    Então, infelizmente, você precisará descartar o PK, alterar a coluna para ter um Collation de 100 níveis (por exemplo Latin1_General_100_CI_AS_SC, ) e, em seguida, recriar o PK. Observe que a diferença entre o Collation sugerido e o Collation atual é o 100 e o _SCno final, o que permite que ele manipule corretamente os caracteres suplementares.

    Isso não significa que você precisa:

    1. alterar os Collations de outras tabelas (a menos que tenham a mesma configuração do NVARCHARPK)
    2. alterar o Collation padrão do banco de dados. O principal problema de não alterar o Collation do banco de dados é que haverá uma diferença de comportamento entre fazer table.column = N'Ș'e @variable = N'Ș'já que variáveis ​​e literais de string usam o Collation padrão do banco de dados.

    Para obter mais exemplos desse comportamento, consulte a seção "Caracteres suplementares" da seguinte postagem do meu blog:

    O Uni-Code: A busca pela lista verdadeira de caracteres válidos para identificadores T-SQL, parte 3 de 2 (identificadores delimitados)

    • 11

relate perguntas