Перенос существующего приложения на прием Unicode
Мы находимся в процессе обновления нашего приложения до полной совместимости с Unicode, поскольку недавно мы получили Delphi 2009, который предоставляет это прямо из коробки. Я ищу всех, у кого есть опыт обновления приложения для приема символов Unicode. Конкретно отвечает на любой из следующих вопросов.
- Нам нужно изменить VarChars на NVarchar, Char на NChar. Здесь есть какие-то подводные камни.
- Нам нужно обновить все операторы sql, чтобы включить N перед любыми строками sql. Таким образом, обновление tbl_Customer set Name = 'Smith' должно стать Update tbl_Customer set Name = N'Smith '. Есть ли способ использовать это по умолчанию для определенных полей. Кажется необычным, что это все еще требуется.
- Можно ли настроить в SQLServer какие-либо параметры по умолчанию, которые упростят эту задачу?
ps Нам также нужно обновить наш код Oracle
Ответы 3
Дэмиен
Я не уверен, насколько полезен ваш ответ. У нас есть большая 700 000 строк скомпилированной кодовой базы, которая была написана за последние десять лет и которая содержит большое количество запросов sql. Большинство из них стандартизированы до нескольких функций, которые являются основой для большинства обновлений базы данных. Их можно очень просто обновить. Однако нам также необходимо проверить каждое предложение where для CustomerName = '% s', которое теперь должно быть CustomerName = N '% s'
Это реальный вопрос, на который нужен реальный ответ.
Oracle не требует, чтобы вы использовали nvarchar для хранения строк Unicode - сервер можно настроить для хранения varchar2 в UTF-8. Если раньше вы поддерживали только ASCII, он должен быть прозрачным. Это должно избавить от необходимости выполнять поиск и замену на стороне приложения для ' - N'.
Что касается точки Дэмиена: это может вам не помочь сейчас, но вы действительно должны сделать своей приоритетной задачей избавление от непараметрических запросов. Они не что иное, как тормоз для вашей системы с точки зрения обслуживания, производительности и безопасности.
Очевидно, что с SQL Server ограничения для nchar / nvarchar составляют половину от их аналогов char / varchar (если вы не перенесете все> 4000 в nvarchar (max))