Делаю запрос по таблицам из Oracle. Курсор по запросу получаю с помощью SqlExec(). Все работает прекрасно. Но длинные символьные поля из Oracle (например varchar2(2000)), которые преобразуются в memo, не перекодируются и отображаются "кракозябрами". Если обрезаю ( Substr(cc,1,254) ), то все нормально, из этого сделал вывод, что memo поля не конвертируются автоматически. Помогите с решением пожалуйста.

Решил проблему таким образом, в Select, к выбираемому полю добавил cast: Cast(spr_role.prim as varchar2(2000)). Все заработала, хотя странно в таблице это поле именного этого типа и есть.



Исправлено 2 раз(а). Последнее : Komar, 14.05.18 12:39

Версия фокса, сервера, оракл-клиента?
Какой используется драйвер - родной оракловский, или МС?
NLS_LANG на клиенте? Кодировка самой БД (параметр с именем NLS_CHARACTERSET в представлении nls_database_parameters)?
SYS(987) в фоксе?

P.S. уверен что на сервере varchar2 а не nvarchar2?
Кроме того, если это сложный запрос с union и/или подзапросами, то тип поля результата может отличаться от типа поля в таблице в одной из частей сложного запроса... Для "вычисляемых" полей вообще всё плохо, особенно с MS драйвером.





Исправлено 1 раз(а). Последнее : Igor Korolyov, 14.05.18 13:03

Fox 9 sp2, Oracle 11.2, драйвер родной. Кодировки все нормальные. Не красиво писало кириллицу только из memo полей курсора, т.е. неверная кодировка получалась (скорее всего) в самой функции фокса sqlexeс(). Все поля любых типов менее 255 символов, или обрезанные до этого, читаются красиво. На сервере точно varchar2 (кстати добавили еще и nvarchar2, картина аналогичная). Запрос простой, прямое чтение.



Исправлено 1 раз(а). Последнее : Komar, 14.05.18 13:25

Похоже, что драйвер ODBC (версия?) чудит varchar переводит в nvarchar.

"Нормальные" это какие? И про SYS(987) молчок... Я лично с такими проблемами не сталкивался (точнее почти все проблемы с кодировками состоят в кривой настройке NLS_LANG на клиенте - предполагая что БД на сервере "в принципе" поддерживает кириллицу, конечно же - т.е. она в CL8MSWIN1251, или AL32UTF8 или на худой конец какой RU8PC866 ).

При работе с юникодным сервером (основная кодировка БД AL32UTF8 - на клиенте, как обычно однобайтная CL8MSWIN1251) в фокс в мемо-поля действительно попадает юникодное содержимое - однако оно всё же визуально отличается от "кракозябр" - ну по крайней мере я "на глаз" обычно определяю юникод и utf8
"Лечится" это как раз настройкой SYS(987, .T.) - тогда фокс сам (видимо, вместе с ODBC драйвером) перекодировкой займётся.

По установкам кодировки все как вы и сказали (основная кодировка БД AL32UTF8 - на клиенте, как обычно однобайтная CL8MSWIN1251), а вот SYS(987) не использовал, т.е стоит по умолчанию. Попробую отпишусь

Установка SYS(987, .T.) помогла, спасибо. Меня смущало, что сбой кириллицы был только на длинных строках (memo).

Ну в "примечаниях" так и написано:

Цитата:

SYS(987) can be used to return remote Varchar data as ANSI for use with Memo fields.

Невнятная статья хелпа по этой теме - по логике текста должно влиять на любые текстовые поля, но влияет только на memo... При том, как помнится, в старых версиях фокса (VFP8 и ранее) функции вообще не было, и проблема не решалась так просто - оставалось лишь "жить" с юникодом в мемо полях, вручную гоняя их через STRCONV для показа фоксовыми средствами...