Я нашел решение, которое работает. Я очень сомневаюсь, что это лучшее решение. Однако это решение я буду реализовывать до тех пор, пока не смогу разрешить переписать весь раздел построения запросов программного обеспечения, над которым я работаю.
В случае:
SELECT P FROM SumTotal.TP.Models.Party.Person P join P.Demographics PD WHERE (PD.LastName LIKE '%カタカ%')
Предложение where содержит этот литерал:
'%カタカ%'
Этот литерал может быть разбит на nchars, которые Hibernate (Nhibernate) неосознанно передаст в SQL, который он генерирует. Странно, но это работает. Таким образом, предыдущий запрос может быть записан как:
SELECT P FROM SumTotal.TP.Models.Party.Person P join P.Demographics PD WHERE (PD.LastName LIKE '%' + nchar(0x30AB) + nchar(0x30BF) + nchar(0x30AB)+ '%')
Это решение далеко от оптимального, потому что для этого потребуется пройти каждый символ и определить, является ли он многобайтовым символом. Однако в случае, когда этот код находится в его приложении, он используется в динамическом генераторе запросов, который обрабатывает несколько различных критериев в рамках различных операций. В приведенном мною примере он ищет юникод в любом месте строки. Вполне возможно, что эта функция может возвращать часть предложения where для столбца, равного конкретному числовому значению, или она может искать начальные символы строки. Метод, который создает оператор, использует тип оператора и термин для возврата строки. Я мог бы переписать это, но это было бы большой задачей. Вышеуказанное исправление позволит мне обработать строку, переданную в этот метод. Я предлагаю это решение, потому что оно работает, но ответ Дарина, вероятно, - лучший способ, который я смог найти.