Início / dba / Perguntas / 250586
Accepted
Doug Coats
Asked: 2019-10-09 12:30:58 +0800 CST

Substitua a função removendo Ones / 1 ao remover char(185) (sobrescrito 1)

  • 772

Ok, como o título sugere, isso está ocorrendo.

Ao usar a REPLACEfunção em char(185) para dados em uma tabela temporária, os ("1") também estão sendo removidos.

Dados do SQL SERVER 2008R2
UNICODE

Agrupamento de banco de dados - agrupar SQL_Latin1_General_CP1_CS_AS Tempdb tem padrão

Qualquer outro detalhe que eu possa fornecer que possa ser útil, me avise.

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    CHAR(185), sendo dados VARCHAR e usando uma página de código de 8 bits, pode ser um caractere diferente dependendo da página de código que está sendo usada (que é determinada pelo agrupamento do banco de dados atual ao usar a CHAR()função). Em muitas páginas de código, incluindo a comum Windows-1252 (Latin1_General), o caractere é um sobrescrito 1 (ou seja, " 1 "). Esse caractere, dependendo da página de agrupamento/código que está sendo usada, pode ter um mapeamento de "melhor ajuste" para um "1" normal.

    Além disso, ao usar um agrupamento do Windows, a diferenciação entre maiúsculas e minúsculas pode afetar o resultado de correspondências entre subscrito, sobrescrito e versões regulares dos mesmos caracteres (sério! veja o exemplo abaixo). Isso também abrange NVARCHARdados / Unicode (incluindo UTF-8 a VARCHARpartir do SQL Server 2019).

    Ao precisar corresponder em caracteres específicos, você precisa usar um agrupamento binário (ou seja, um que termine em _BIN2, a menos que no SQL Server 2005 ou anterior, caso em que apenas os _BINagrupamentos estão disponíveis).

    SELECT CHAR(185)
WHERE  CHAR(185) = '1' COLLATE SQL_Latin1_General_CP1_CI_AS
-- no rows (SQL Server collation, code page 1252, case insensitive)



SELECT CHAR(185)
WHERE  CHAR(185) = '1' COLLATE SQL_Latin1_General_CP437_CI_AS
-- 1 row (SQL Server collation, code page 437, case insensitive)

SELECT CHAR(185)
WHERE  CHAR(185) = '1' COLLATE SQL_Latin1_General_CP437_CS_AS
-- 1 row (SQL Server collation, code page 437, case sensitive)



SELECT CHAR(185)
WHERE  CHAR(185) = '1' COLLATE Latin1_General_100_CI_AS
-- 1 row (Windows collation, code page 1252, case insensitive)

SELECT CHAR(185)
WHERE  CHAR(185) = '1' COLLATE Latin1_General_100_CS_AS
-- no rows (Windows collation, code page 1252, case sensitive)



SELECT CHAR(185)
WHERE  CHAR(185) = '1' COLLATE Latin1_General_100_BIN2;
-- no rows (Windows collation, code page 1252, _BIN2 collation; always works!)

    Conforme observado acima, os dados Unicode (independentemente do tipo de agrupamento) funcionam da mesma forma que VARCHARos dados usados ​​com um agrupamento do Windows (porque ambos os cenários usam as mesmas regras Unicode):

    SELECT NCHAR(185)
WHERE  NCHAR(185) = N'1' COLLATE Latin1_General_100_CI_AS
-- 1 row (Windows collation, Unicode data, case insensitive)

SELECT NCHAR(185)
WHERE  NCHAR(185) = N'1' COLLATE Latin1_General_100_CS_AS
-- no rows (Windows collation, Unicode data, case sensitive)
    • 2

  2. Caso alguém queira saber - o problema era o agrupamento. Quando escrevi a pergunta, não percebi que a tabela #temp que estava usando tinha um agrupamento diferente do padrão para o banco de dados em que estava trabalhando. Foi uma solução simples e honestamente algo que eu deveria ter pensado muito antes de vir aqui com perguntas.

    • 0

relate perguntas