Не удалось вернуть запрос тайских данных

Две проблемы:

1. Строка, передаваемая в предложение LIKE, имеет вид VARCHAR из-за того, что перед ней не стоит заглавная буква «N». Например:

   SELECT 'อุตรดิตถ์' AS [VARCHAR], N'อุตรดิตถ์' AS [NVARCHAR]
   -- ?????????        อุตรดิตถ
   

   Здесь происходит следующее: когда SQL Server анализирует пакет запросов, ему необходимо определить точный тип и значение всех литералов/констант. Таким образом, он вычисляет, что 12 — это INT, а 12.0 — это NUMERIC и т. д. Он знает, что N'ดิ' — это NVARCHAR, который является всеобъемлющим набором символов, поэтому он принимает значение как есть. НО, как отмечалось ранее, 'ดิ' — это VARCHAR, что является 8-битной кодировкой, что означает, что набор символов контролируется кодовой страницей. Для строковых литералов и переменных/параметров кодовая страница, используемая для VARCHAR данных, является сопоставлением базы данных по умолчанию. Если в строке есть символы, недоступные на кодовой странице, используемой сопоставлением базы данных по умолчанию, они либо преобразуются в сопоставление «наилучшего соответствия», если такое сопоставление существует, либо становятся символом замены по умолчанию: ?.

   С технической точки зрения, поскольку сопоставление базы данных по умолчанию управляет строковыми литералами (и переменными) и поскольку существует кодовая страница для «тайского языка» (доступная в сопоставлениях Windows), то можно было бы иметь строку VARCHAR, содержащую тайские символы (что означает: 'ดิ', без префикса "N", будет работать). Но это потребует изменения сортировки базы данных по умолчанию, и это НАМНОГО больше работы, чем просто префикс строкового литерала с «N».

   Подробный обзор этого поведения см. в моей серии из двух частей:

   • Which Collation is Used to Convert NVARCHAR to VARCHAR in a WHERE Condition? (Part A of 2: “Duck”)
   • Какое сопоставление используется для преобразования NVARCHAR в VARCHAR в условии WHERE? (Часть B из 2: «Кролик»)

2. Вам нужно добавить подстановочные знаки с обоих концов:
   N'%อุตรดิตถ์%'

Конечный результат будет выглядеть так:

WHERE [Province] LIKE N'%อุตรดิตถ์%'

EDIT:
Я только что отредактировал вопрос, чтобы отформатировать «результаты», чтобы они были более удобочитаемыми. Теперь кажется, что следующее может также работать (поскольку в предикате LIKE в вопросе не используются подстановочные знаки):

WHERE [Province] = N'อุตรดิตถ์'

EDIT 2:
Строка (то есть что-то внутри одинарных кавычек) равна VARCHAR, если перед строковым литералом нет префикса "N". Тип данных назначения не имеет значения (например, столбец NVARCHAR(255)). Проблема здесь заключается в типе данных source, и этот источник является строковым литералом. И в отличие от string в .NET, SQL Server обрабатывает 'string' как 8-битную кодировку (VARCHAR; значения ASCII 0–127 одинаковы для всех кодовых страниц, расширенные значения ASCII 128–255, определяемые кодовой страницей, и, возможно, 2-байтовые последовательности для двухбайтовых наборов символов) и N'string' как UTF-16 Little Endian (NVARCHAR; набор символов Unicode, 2-байтовые последовательности для символов BMP от 0 до 65535, две 2-байтовые последовательности для кодовых точек выше 65535). Использование 'string' аналогично передаче переменной VARCHAR. Например:

DECLARE @ASCII VARCHAR(20);
SET @ASCII = N'อุตรดิตถ์';
SELECT @ASCII AS [ImplicitlyConverted]
-- ?????????

Может быть несколько вещей!

Сначала распечатайте значение столбца и строку запроса в шестнадцатеричном формате.

SELECT     convert(varbinary(20)Province) as stored convert(varbinary(20),'อุตรดิตถ์') as query from allDistricsBranches;

Это должно дать вам некоторое представление о проблеме. Я думаю, что наиболее вероятной причиной является ввод символов ั, ิ в неправильной последовательности. Они отображаются как часть основной буквы, но хранятся внутри как отдельные символы.