Minha resposta inicial sugeriu que o sinalizador ANSI_PADDING definido como OFF pode ser o culpado pela diferença de comportamento. No entanto, isso está incorreto; esse sinalizador afeta apenas o armazenamento, mas não a comparação de igualdade.
A diferença decorre da implementação do padrão SQL pela Microsoft . O padrão afirma que, ao verificar a igualdade, as duas strings esquerda e direita do operador de igualdade precisam ser preenchidas para ter o mesmo comprimento . Isso explica os seguintes resultados:
insert into test_padding (varchar_clmn, nvarchar_clmn) values ('space ', 'nspace ')
go
-- equality for varchar column
select count(*) from test_padding where varchar_clmn = 'space' -- returns 1
select count(*) from test_padding where varchar_clmn = 'space ' -- returns 1
select count(*) from test_padding where varchar_clmn = 'space ' --returns 1
-- equality for nvarchar column
select count(*) from test_padding where nvarchar_clmn = 'nspace' -- returns 1
select count(*) from test_padding where nvarchar_clmn = 'nspace ' -- returns 1
select count(*) from test_padding where nvarchar_clmn = 'nspace ' --returns 1
O operador LIKE não preenche seus operandos. Ele também se comporta de maneira diferente para os tipos VARCHAR
e NVARCHAR
colunas :
-- likeness for varchar column
select count(*) from test_padding where varchar_clmn like 'space' -- returns 1
select count(*) from test_padding where varchar_clmn like 'space ' -- returns 1
select count(*) from test_padding where varchar_clmn like 'space ' -- returns 0
-- likeness for nvarchar column
select count(*) from test_padding where nvarchar_clmn like 'nspace' -- returns 0
select count(*) from test_padding where nvarchar_clmn like 'nspace ' -- returns 1
select count(*) from test_padding where nvarchar_clmn like 'nspace ' -- returns 0
O comportamento do operador LIKE para o tipo ASCII é específico do SQL Server; para o tipo Unicode, é compatível com ANSI.
MyString+'x' = ltrim(rtrim(MyString))+'x'
conforme sugerido neste blog