Como criar uma nova coluna no SELECT CASE quando a string contém palavras em árabe?

Como você está usando Unicode / UTF-16 (ou seja NVARCHAR), você não precisa do CASTou mesmo de um Arabic_*agrupamento. O único requisito para literais de string é prefixá-los com "N" maiúsculo:

SELECT 'قدوم' COLLATE Arabic_CI_AS, '-o-' AS [-o-], 'رجوع' COLLATE Arabic_CI_AS;
-- ???? -o- ????

SELECT N'قدوم' COLLATE French_CI_AS, '-o-' AS [-o-], N'رجوع' COLLATE French_CI_AS;
-- قدوم -o- رجوع

^{(o -o-campo é usado como separador para evitar que a formatação Bi-Direction, inerente aos pontos de código árabe e hebraico, exiba a segunda coluna à esquerda no comentário T-SQL abaixo da consulta quando renderizada em HTML)}

Ao usar NVARCHAR(incluindo NCHARe o should-never-be-used NTEXT), a codificação é sempre UTF-16, portanto, o conjunto de caracteres nunca muda (é sempre Unicode, que é um conjunto de caracteres único). Nesse caso, o agrupamento afeta principalmente a classificação e as comparações (o que não está sendo feito aqui).

Se você estivesse usando VARCHAR, seria necessário um agrupamento em árabe para definir a página de código para oferecer suporte aos caracteres árabes (página de código do Windows 1256).

A razão pela qual sua inicial 'قدوم'retornou ????é que a string literal não foi prefixada com N, tornando-a uma VARCHARstring, nesse caso ela foi convertida para a página de código associada ao agrupamento padrão do banco de dados atual que você estava usando, que claramente não era um árabe agrupamento. Essa conversão acontece quando a consulta é analisada inicialmente, o que significa que sua string já estava ???? antes da operação de conversão convertê-la em NVARCHAR. Se você estivesse usando um banco de dados que tivesse um agrupamento padrão em árabe, seu literal de string funcionaria mesmo sem o Nprefixo, e o CASTto NVARCHARseria igualmente desnecessário.

 
Para obter mais informações sobre como trabalhar com strings/codificações/Unicode/collations, visite meu site: Collations Info

PS Eu recomendaria que você não fizesse JOINs de estilo antigo, como FROM TableA, TableB WHERE TableA.JoinColumn = TableB.JoinColumn. Embora essa sintaxe não tenha sido preterida, a sintaxe de junção externa relacionada — *=e =*— na verdade foi removida no SQL Server 2005 . Portanto, para consistência (e pessoalmente, eu também adicionaria legibilidade), você deve usar a INNER JOINcláusula. Além disso, é sempre melhor prefixar os nomes dos objetos com o nome do Schema. O resultado final é:

FROM dbo.TableA
INNER JOIN dbo.TableB
        ON TableB.JoinColumn = TableA.JoinColumn

Nesse caso, porque você está usando um NVARCHARtipo de dados em sua conversão que dá suporte a todo o conjunto de caracteres Unicode , tudo o que está faltando no prefixo da string ad-hoc é o Ncaractere para significar para o SQL Server tratar a string como NVARCHAR, nesse ponto torna sua CAST()chamada de função redundante e também não é necessária. Por exemplo SELECT N'Some Text', irá produzir uma NVARCHARstring ao invés de apenas SELECT 'Some Text'que produz uma VARCHARstring.

A resposta de Solomon Rutzky também fornece um exemplo claro disso, com informações mais perspicazes.

Para quem se deparar com esse problema ao usar VARCHARtipos de dados (ou semelhantes), abaixo estão os droids que você está procurando :

Você precisa usar um caractere árabe com suporte para agrupamento na coluna, para a tabela, no banco de dados ou no nível de instância do servidor, como Arabic_CI_AI_KS_WS.

Esta resposta do StackOverflow tem boas informações sobre ela.

Para consultas e valores ad hoc, você deve poder usar a COLLATEfunção conforme necessário. Por exemplo, com sua consulta acima, se precisávamos usar VARCHAR:

SELECT
    case 
        when (CAST(o.startTime as time(7)) > cast(Start as time(7))) then  cast(N'قدوم' COLLATE Arabic_CI_AI_KS_WS as varchar(55)) 
        else cast(N'رجوع' COLLATE Arabic_CI_AI_KS_WS as varchar(55)) end as stat,
    userId, 
    FirstName 
from Users,TimeTable