Проблемы с турецким сопоставлением SQL (турецкий язык “я”)
Симпи, вы можете сделать так для сценария опции:
<option value="<?php echo $rows["Product"];?>" <?=$rows['Product']=='//your val'?"selected":""?>><?php echo $rows["Product"]; ?></option>
<?php } ?>
6 ответов
Оказывается, что лучшим решением было бы фактически провести рефакторинг всего SQL и кода.
В последние несколько дней я написал приложение для рефакторинга, чтобы исправить все сохраненные функции и функции. , представления, имена таблиц должны быть согласованными и использовать правильный регистр, например:
select unitid from dbo.unit
будет изменен на
select UnitId from dbo.Unit
. Затем приложение также просматривает код и заменяет любые вхождения хранимого процесса и его параметров и корректирует их в соответствии с регистром. определяется в БД. Для всех таблиц данных в приложении задана инвариантная локаль (спасибо FXCop за указание всех таблиц данных ...), это предотвращает чувствительность к регистру вызовов внутри кода.
Если кому-то захочется приложение или какой-либо совет по В процессе вы можете связаться со мной по адресу dotnetvixen@gmail.com.
Я разработал очень много систем с поддержкой турецкого языка, и это хорошо известная проблема, как вы сказали.
Лучшая практика - изменить настройки базы данных на UTF-8, и все. Это должно решить все проблемы.
Вы можете столкнуться с проблемами, если хотите поддерживать чувствительность к регистру в (ı-I, i-İ), которая может быть проблематичной для поддержки в SQL Server. Если весь вход поступает из Интернета, убедитесь, что это также UTF-8.
Если вы сохраните вход Web UTF-8 и настройки SQL Server как UTF-8, все должно пройти гладко.
Возможно, я не понимаю проблему здесь, но разве это не более вероятно, потому что база данных чувствительна к регистру, а ваш запрос - нет? Например, в Sybase я могу сделать следующее:
USE master
GO
EXEC sp_server_info 16
GO
Что говорит мне, что моя база данных нечувствительна к регистру:
attribute_id attribute_name attribute_value
16 IDENTIFIER_CASE MIXED
Если вы можете изменить используемое сопоставление затем попробуйте инвариантную локаль. Но убедитесь, что вы не влияете на другие вещи, такие как имена и адреса клиентов. Если клиент привык к поиску своего имени без учета регистра, ему не понравится, если я и я перестанем быть эквивалентными или я и я перестану быть эквивалентными.
Можно ли изменить параметры сортировки базы данных на значения по умолчанию: при этом все ваши текстовые столбцы останутся с турецкой сортировкой?
Запросы будут работать, но данные будут работать правильно. Теоретически ...
Есть некоторые ошибки с временными таблицами и табличными переменными с столбцами varchar: вам придется добавить к ним предложения COLLATE
Я понимаю, что вы не хотите проходить через все хранимые процедуры, чтобы исправить проблему, но, возможно, у вас все будет в порядке, чтобы использовать инструмент рефакторинга для решения проблемы. Я говорю, взгляните на SQL Refactor . Я не использовал его, но выглядит многообещающе.