Existem dois comportamentos diferentes na resposta do Cade Roux:a substituição é bem-sucedida (quando a ordenação SQL é usada) e malsucedida (a ordenação do Windows é usada). O motivo está no tipo de agrupamento usado.
Esse comportamento foi enviado à Microsoft há quase 4 anos:
P: Ao tentar substituir um caractere NUL por replace(), isso funciona se o valor tiver um agrupamento SQL, mas não um agrupamento do Windows.
R: Isso se deve ao fato de 0x0000 ser um caractere indefinido em Windowscollations. Todos os caracteres indefinidos são ignorados durante a comparação, classificação e correspondência de padrões. Portanto, pesquisar por 'a' + char(0) é realmente procurar por 'a', e pesquisar por char(0) é equivalente a uma string vazia.
A maneira de lidar com caracteres indefinidos é um pouco confusa, mas esta é a maneira que o Windows definiu para classificá-los, e o SQL Server está em conformidade com a API geral do Windows.
No agrupamento SQL, não há noção de caractere indefinido. Cada ponto de código é atribuído a um peso, é por isso que não vemos um problema lá.
mas infelizmente ainda não está documentado.
Portanto, parece que a única solução é alterar o agrupamento para agrupamento SQL (por exemplo,
SQL_Latin1_General_CP1_CI_AS pode ser usado também). Eu removi minha resposta anterior como desnecessária
