Por que os servidores vinculados têm uma limitação de 10 ramificações em uma expressão CASE?

Claramente não há uma CASEexpressão aninhada aqui.

Não no texto da consulta, não. Mas o analisador sempre expande CASEas expressões para a forma aninhada:

SELECT CASE SUBSTRING(p.Name, 1, 1)
        WHEN 'a' THEN '1' 
        WHEN 'b' THEN '2' 
        WHEN 'c' THEN '3' 
        WHEN 'd' THEN '4' 
        WHEN 'e' THEN '5' 
        WHEN 'f' THEN '6' 
        WHEN 'g' THEN '7' 
        WHEN 'h' THEN '8' 
        WHEN 'i' THEN '9' 
        WHEN 'j' THEN '10' 
        WHEN 'k' THEN '11'  
    END
FROM AdventureWorks2012.Production.Product AS p

Essa consulta é local (sem servidor vinculado) e o Compute Scalar define a seguinte expressão:

Isso é bom quando executado localmente, porque o analisador não vê uma CASEinstrução aninhada com mais de 10 níveis de profundidade (embora passe uma para os estágios posteriores da compilação da consulta local).

No entanto, com um servidor vinculado, o texto gerado pode ser enviado ao servidor remoto para compilação. Se for esse o caso, o analisador remoto vê uma CASEinstrução aninhada com mais de 10 níveis de profundidade e você obtém o erro 8180.

Outra esquisitice. Esta função com valor de tabela embutida produz o mesmo erro

A função in-line é expandida no local no texto da consulta original, portanto, não é surpresa que os mesmos resultados de erro ocorram com o servidor vinculado.

Mas um TVF de várias instruções semelhante funciona bem

Parecidos, mas não iguais. O msTVF envolve uma conversão implícita para varchar(max), que acontece para evitar que a CASEexpressão seja enviada ao servidor remoto. Como o CASEé avaliado localmente, um analisador nunca vê um excesso de aninhamento CASEe não há erro. Se você alterar a definição da tabela varchar(max)para o tipo implícito do CASEresultado - varchar(2)- a expressão será remota com o msTVF e você receberá um erro.

Por fim, o erro ocorre quando um over-nested CASEé avaliado pelo servidor remoto. Se o CASEnão for avaliado no iterador de Consulta Remota, não haverá erro. Por exemplo, o seguinte inclui um CONVERTque não é remoto, portanto, nenhum erro ocorre mesmo que um servidor vinculado seja usado:

SELECT CASE CONVERT(varchar(max), SUBSTRING(p.Name, 1, 1))
        WHEN 'a' THEN '1' 
        WHEN 'b' THEN '2' 
        WHEN 'c' THEN '3' 
        WHEN 'd' THEN '4' 
        WHEN 'e' THEN '5' 
        WHEN 'f' THEN '6' 
        WHEN 'g' THEN '7' 
        WHEN 'h' THEN '8' 
        WHEN 'i' THEN '9' 
        WHEN 'j' THEN '10' 
        WHEN 'k' THEN '11'  
    END
FROM SQL2K8R2.AdventureWorks.Production.Product AS p

Meu palpite é que a consulta está sendo reescrita em algum lugar ao longo do caminho para ter uma CASEestrutura ligeiramente diferente, por exemplo

CASE WHEN column = 'a' THEN '1' ELSE CASE WHEN column = 'b' THEN '2' ELSE ...

Acredito que seja um bug em qualquer provedor de servidor vinculado que você esteja usando (na verdade, talvez em todos eles - já vi isso relatado em vários). Eu também acredito que você não deve prender a respiração esperando por uma correção, seja na funcionalidade ou na mensagem de erro confusa explicando o comportamento - isso é relatado há muito tempo, envolve servidores vinculados (que não tiveram muito amor desde o SQL Server 2000) e afeta muito menos pessoas do que esta mensagem de erro confusa , que ainda não foi corrigida após a mesma longevidade.

Como Paul aponta , o SQL Server está expandindo sua CASEexpressão para a variedade aninhada, e o servidor vinculado não gosta disso. A mensagem de erro é confusa, mas apenas porque a conversão subjacente da expressão não é imediatamente visível (nem intuitiva de forma alguma).

Uma solução alternativa (além da alteração de função que você adicionou à sua pergunta) seria criar uma exibição ou procedimento armazenado no servidor vinculado e fazer referência a isso, em vez de passar a consulta completa por meio do provedor do servidor vinculado.

Outro (supondo que sua consulta seja realmente simplista e você queira apenas o coeficiente numérico das letras az) é ter:

SELECT [col] = RTRIM(ASCII([column])-96)
FROM LinkedServer.database.dbo.table;

Se você realmente precisa que isso funcione como está, sugiro que entre em contato com o suporte diretamente e abra um caso, embora eu não possa garantir os resultados - eles podem apenas fornecer soluções alternativas às quais você já tem acesso nesta página.

você pode contornar isso por

SELECT COALESCE(
CASE SUBSTRING(p.Name, 1, 1)
    WHEN 'a' THEN '1' 
    WHEN 'b' THEN '2' 
    WHEN 'c' THEN '3' 
    WHEN 'd' THEN '4' 
    WHEN 'e' THEN '5' 
    WHEN 'f' THEN '6' 
    WHEN 'g' THEN '7' 
    WHEN 'h' THEN '8' 
    WHEN 'i' THEN '9' 
    ELSE NULL
END,
CASE SUBSTRING(p.Name, 1, 1)
    WHEN 'j' THEN '10' 
    WHEN 'k' THEN '11'  
END)
FROM SQL2K8R2.AdventureWorks.Production.Product AS p

Outra solução alternativa para esse problema é usar a lógica baseada em conjunto, substituindo a CASEexpressão por uma junção esquerda (ou aplicação externa) a uma tabela de referência ( refno código abaixo), que pode ser permanente, temporária ou uma tabela/CTE derivada. Se isso for necessário em várias consultas e procedimentos, prefiro ter isso como tabela permanente:

SELECT ref.result_column AS [col] 
FROM LinkedServer.database.dbo.table AS t
  LEFT JOIN
    ( VALUES ('a',  '1'),
             ('b',  '2'), 
             ('c',  '3'),
             ---
             ('j', '10'),
             ('k', '11')
    ) AS ref (check_col, result_column) 
    ON ref.check_col = t.column ;

uma maneira de contornar isso é incluir o teste na whencláusula, ou seja,

case
  when SUBSTRING(p.Name, 1, 1) = 'a' THEN '1'
...