Agrupar problemas com caracteres errados

Este é um problema de codificação incorreto. Os caracteres estão vindo codificados como página de código DOS 850, mas a página de código de destino que você está usando (com base nos Latin1_Generalagrupamentos) é a página de código 1252 do Windows. Por exemplo, na página de código DOS 850, o Çcaractere tem um valor de 0x80 (ou 128 em Decimal). No entanto, esse mesmo valor de 0x80 na página de código do Windows 1252 fornece €. Da mesma forma, Ãem DOS Code Page 850 tem um valor de 0xC7 (ou 199 em Decimal). No entanto, esse mesmo valor de 0xC7 na página de código do Windows 1252 fornece Ç.

Os caracteres incorretos estão incorretos porque foram importados para o SQL Server com a codificação incorreta especificada para a origem. Isso não está acontecendo no SQL Server, pois seria um problema de conversão de página de código; nesse caso, o mesmo "caractere" teria seu valor traduzido para o mesmo caractere na página de código de destino (se o caractere existir na página de código de destino, senão você consegue ?). Por exemplo:

SELECT ASCII('Ç' COLLATE Latin1_General_CI_AS) AS [CP1252 Value],
       'Ç' COLLATE SQL_Latin1_General_CP850_CI_AS AS [CharacterInCP850],
       ASCII('Ç' COLLATE SQL_Latin1_General_CP850_CI_AS) AS [CP850 Value];

Devoluções:

CP1252 Value     CharacterInCP850     CP850 Value
199              Ç                    128

Ou seja, isso está acontecendo provavelmente durante uma importação de arquivo - BCP.exe , SQLCMD.exe , BULK INSERT, OPENROWSET(BULK...), código de aplicativo personalizado que lê um arquivo, etc - onde a página de código de origem errada está sendo especificada ou nenhuma página de código é especificado para a fonte. Se estiver sendo feita uma importação que especifica a página de código 1252 para este arquivo, ela terá o efeito que você está vendo aqui, pois esses bytes são codificados para a página de código 850, não a página de código 1252.

Deve-se notar que isso também pode acontecer com dados vindos do código do aplicativo se o driver (ODBC, etc) estiver sendo instruído a usar a página de código errada.

Agora, sobre o método de correção disso:

1. Idealmente, o método de importação dos dados seria atualizado/fixado para contabilizar adequadamente a página de código real com a qual os dados foram codificados.
2. Se não for possível corrigir o processo de importação, a função que a outra empresa forneceu não é o melhor caminho a seguir. Na verdade, é provavelmente a abordagem mais lenta e complicada que também é propensa a erros (se eles não mapearam todos os caracteres). Não há razão para fazer dois loops ao SUBSTRINGcarregar os caracteres, em pares, em uma variável de tabela que permitiria um único loop usando a REPLACEfunção. E usar a ASCIIfunção e um Collation sensível a maiúsculas e minúsculas é desnecessário e propenso a erros (se dois caracteres corresponderem ao que está sendo procurado) ao usar um _BIN2Collation teria sido melhor.

3. Use a seguinte função que faz a conversão. Primeiro ele pega os bytes da string atual, então ele injeta esses bytes em uma VARCHARcoluna que usa Code Page 850, então ele seleciona esse valor da variável de tabela em uma variável local (necessária de qualquer maneira para retornar o valor) que tem o efeito de convertendo a string na página de código usada pelo agrupamento padrão do banco de dados (que aqui teria que ser a página de código 1252, caso contrário você não estaria obtendo a string "correta" da função):

   USE [tempdb];
   GO
   CREATE FUNCTION dbo.FixCodePage850toCodePage1252
   (
       @CodePage850String VARCHAR(8000)
   )
   RETURNS VARCHAR(8000)
   WITH SCHEMABINDING
   AS
   BEGIN
     DECLARE @Convert850to1252 TABLE
     (
       [String] VARCHAR(8000) COLLATE SQL_Latin1_General_CP850_CI_AS
     );
     DECLARE @ReturnValue VARCHAR(8000);
   
     INSERT INTO @Convert850to1252 ([String])
     VALUES (CONVERT(VARBINARY(8000), @CodePage850String, 0));
   
     SELECT @ReturnValue = [String] -- automatic conversion to Code Page of database
     FROM @Convert850to1252;
   
     RETURN @ReturnValue;
   END;
   GO
   

   Testar ambas as funções retorna os mesmos resultados:

   SELECT dbo.fixcollation('lj§ ULTRASSONICO-LOCA€AO (NOTA SERVI€O)');
   -- Ãëº ULTRASSONICO-LOCAÇAO (NOTA SERVIÇO)
   
   SELECT dbo.FixCodePage850toCodePage1252('lj§ ULTRASSONICO-LOCA€AO (NOTA SERVI€O)');
   -- Ãëº ULTRASSONICO-LOCAÇAO (NOTA SERVIÇO)
   

Eu criei um teste para verificar os mapeamentos de todos os caracteres caso a empresa que fornece a função de tradução tenha perdido algum mapeamento. Eu filtrei os caracteres gráficos e o "i" sem ponto que são encontrados apenas na página de código 850.

USE [tempdb];
GO
;WITH nums AS
(
    SELECT TOP (256) (ROW_NUMBER() OVER (ORDER BY (SELECT 0)) - 1) AS [num]
    FROM   master.sys.columns
), vals AS
(
  SELECT nums.[num] AS [Value],
         CHAR(nums.[num]) AS [Character],
         dbo.fixcollation(CHAR(nums.[num])) AS [OldWay],
         dbo.FixCodePage850toCodePage1252(CHAR(nums.[num])) AS [NewWay]
  FROM   nums
)
SELECT vals.*,
       ASCII(vals.[NewWay]) AS [NewValue]
FROM   vals
WHERE  vals.[Character] <> vals.[NewWay] COLLATE Latin1_General_BIN2
AND    vals.[OldWay] <> vals.[NewWay] COLLATE Latin1_General_BIN2
AND    vals.[Value] NOT IN (176, 177, 178, 179, 180, 185, 186, 187, 188,
                            191, 192, 193, 194, 195, 196, 197, 200, 201,
                            202, 203, 204, 205, 206, 217, 218, 219, 220,
                            223, 254, 213); -- characters only in CP850

Isso retorna uma lista de 52 caracteres que poderiam ter passado pelo processo de importação mal traduzidos como os outros, mas ignorados pela UDF que você foi fornecida por aquela outra empresa que lida apenas com 46 dos 98 caracteres aparentemente possíveis.