Pull to refresh

Comments 17

> Web-программисты предпочли ODBC

Рука бойцов facepalm устала.
Надо сказать, что результирующий набор, возвращаемый Caché ODBC, всегда имеет кодировку CP1251 (вне зависимости от типа установки Caché — 8-бит (локализация RUW8) или Unicode (RUSW)). По крайней мере, я не знаю, как это изменить.

Попробуйте включить параметр Unicode SQLTypes.
А если его всё-таки добавить?

Ссылка корявая.
Ссылка имелась в виду:
Details of the ODBC Initialization File

Пробовал задавать этот параметр в Cache ODBC Windows DSN. Ноль эффекта, метаданные возвращаются те же, и кодировка CP1251 (даже с Юникодовской базы).

Возможно, дело в этом: «This functionality is only relevant if you are working with a multibyte character set, such as in Chinese, Hebrew, Japanese, or Korean locales».
Толку-то его пробовать, если этот параметр даже под Windows не работает? В качестве клиента использовал WinSQL. Кодировку возвращаемых данных смотрел по логу CacheODBC.log. Всегда CP1251. У Вас иначе?
Как не работает под Windows?

По ссылке выше я приводил пример на VBScript.
Если параметру присвоить 0 или вовсе убрать, то программа перестаёт правильно работать.

Включил ODBC-лог.
Вот, что у меня в него попадает с включённым параметром и без такового:
Unicode Client Version: 2013.1.0.346.1
Locale Setting: Romanian_Romania.1250

Locale Setting в данном случае означает текущую локаль ОС для дат, времени и т.д.

Поменял в «Панели управления» -> «Язык и региональные настройки» с румынского на немецкий и вот, что получаю в файл теперь:
Unicode Client Version: 2013.1.0.346.1
Locale Setting: German_Germany.1252

PS: для iODBC Unicode вместо libcacheodbc.so нужно использовать libcacheodbciw.so:
Key File Names
А вот unixODBC есть похоже только для 8-бит:
ODBC Support
> Если параметру присвоить 0 или вовсе убрать, то программа перестаёт правильно работать

А у меня с российской локалью всё едино… работает в обоих случаях, причём совершенно одинаково. Возможно, стоило сместить акцент в статье: мы боролись не _против_ кодировки CP1251, т.к. она нас (точнее, php-шников) вполне устаивала. Поэтому мы боролись _за_ неё и (малой кровью) победили.

Всё равно, за комментарии спасибо!
А у меня с российской локалью всё едино… работает в обоих случаях, причём совершенно одинаково.
Работает "что": Ваша программа или моя?
Обе.
Вашу, правда, «русифицировать» пришлось: сделал поиск по вхождению (LIKE) русского префикса.
Каков был смысл менять мой пример?

Я ведь специально создал такую строку с символами сразу из нескольких языков (французский + русский + румынский), чтобы не было сомнений в использовании Unicode.
Сомнений в Unicode у меня и так не было: ChrW(1058) — какие уж тут сомнения.

Но и в первоначальном виде ваш пример у меня одинаково работает с обоими значениями параметра Unicode SQLTypes. Подключался к Cache Unicode.
Вы правы, Виталий, разница-таки есть.

Если Unicode SQLTypes=0, строка «Caché+запрос+bună» превращается в «Cache+запрос+buna», хотя и сохраняет свою «юникодность».

Не сразу сообразил, что увидеть это можно, запуская
wscript servit.vbs (а не сscript servit.vbs, по понятным, в общем-то, причинам). Или записывая rs.Mission в файл.

Пожалуй что тему можно закрывать, ещё раз спасибо.
Подправил статью с учётом сказанного выше. Она про использование 8-битного варианта драйвера, теперь об этом сказано явно. Про Unicode — как-нибудь в другой раз.
Sign up to leave a comment.