Я думаю, что здесь есть две проблемы.
Во-первых, на SQL сервере строковые литералы с широкими символами требуют префикса N
:
b.reward + N'¤'
Во-вторых, кодировка символов для файла * .resx, вероятно, неправильная, или вы по крайней мере видите символ в окне, даже если Sql Сервер не прочитал его должным образом.
Если бы это работало несколько дней go, возможно, кто-то открыл и сохранил файл с программой, которая знает только, как сделать ASCII, и ваш специальный символ был искажен. Вам нужно будет исправить файл.
Если это произошло из окна отладки Visual Studio, которое печально известно тем, что искали значения, пытаясь быть «полезным», вы можете даже не искать в нужном месте.
У меня также есть три вопроса для вас отдельно от вопроса.
Глядя на SQL, это не будет хорошо работать. Происходящая здесь конкатенация делает любые индексы в этих столбцах бесполезными. Вы получите намного лучшую производительность ... возможно, на несколько порядков, если вы структурируете запрос так, чтобы не требовалось объединять эти столбцы. По крайней мере, возможно вычисляемый столбец с индексом FULL-TEXT мог бы сделать этот запрос значительно быстрее.
Логически SQL также выполняет дополнительную работу. Если столбцы beward
, beroom
, beidnr
уже совпадают между двумя таблицами, вам нужно только объединить и проверить ОДНУ из них на входе @SCHEDULE
. Они имеют одинаковые значения, поэтому, если одно соответствует (или нет), другое должно иметь тот же результат.
В будущем, пожалуйста, ВСТАВЬТЕ КОД в свой вопрос. Изображения здесь не так хороши. Это также экономит вашу работу.