Имеется windows XP , VFP 9, oracle 8.1.7
Доступ осуществляется через ODBC. В запросах, где в критерии отбора имеется кириллица, всегда пусто.
к примеру : select * from users where username='ИВАНОВ'
хотя точно знаю, что ИВАНОВ есть. Тип поля username VARCHAR2.
тот же запрос в SQLPlus прекрасно отрабатывает.
Может в ODBC надо чего подкрутить?

Работая с базами MSSQL и PostgreSQL (так же через ODBC) такого безобразия не обнаружил.

Выдала две записи в курсоре
Record# username
1 ЇЇЇЇЇЇ
2 ЇЇЇЇЇЇ

если писать select username from users
то получается все верно
Record# username
1 ИВАНОВ
2 ПЕТРОВ
......

если писать select username from users where username=chr(200)||chr(194)||chr(192)||chr(205)||chr(206)||chr(194)
то получается все верно
Record# username
1 ИВАНОВ

ORAselect1 .Посмотри, какая таблица в оракле применена, а какая - в фоксе.
2. Попробуй параметризованное представление передав параметр - строку "ИВАНОВ"

1. NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
2. так и делаю : select * from users where username='ИВАНОВ' но курсор получается пустой
если запрос такой: select username from users where username=chr(200)||chr(194)||chr(192)||chr(205)||chr(206)||chr(194)
то все нормально.
Такое ощущение что при первом запросе кириллица передается в формате UTF-8, хотя в фоксе codepage=1251,collate=RUSSIAN.

Заботин А.Проверьте следующие пункты:
1. ODBC драйвер должен быть ТОЛЬКО от Oracle
2. Переменная среды NLS_LANG должна быть AMERICAN_CIS.CL8MSWIN1251

1. а через другой драйвер и вряд ли удастся подключиться.
2. у меня стоит NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1, если поставить AMERICAN_CIS.CL8MSWIN1251 все поля с кириллицей выводятся знаками вопроса.

Vch1Проверьте параметр NLS_LANG на сервере и на клиентской машине.
Я использую AMERICAN_AMERICA.CL8MSWIN1251
Вы пытаетесь использовать разные кодировки - в фоксе 1251 - на сервере 855

Проверил и на сервере и на клиентской машине стоит AMERICAN_AMERICA.WE8ISO8859P1,
если ставить и там и там AMERICAN_AMERICA.CL8MSWIN1251 кириллицы вообще не наблюдается.

ORAselectИтак, параметр в реестре не имеет к моему вопросу отношения. Я спросил о собственно БД, и что в реестре - неважно. Каждая БД имеет свой параметр и определяется он в ORACLE/ Почитайте именно об этом - проблема пройдет.

И как называется этот параметр?

Кстати, попробовал те же манипуляции проделать из другой оболочки TurboDelphi.
Все прекрасно работает! Правда, справедливости ради я использовал компоненты TADOTable,TDataSource,TDBGrid.

Vch1Кодировка WE8ISO8859P1 - это восточная европа - 8 бит. Кодировка устанавливается при инсталяции оракла и изменению не подлежит, т.е. изменение параметра не изменяет кодировку уже имеющихся данных. Только новая инсталляция - это вопросы к форуму оракла.
На фокс-клиенте вы устанавливаете кодировку 1251. Я же вам сказал что вы работаете в разных кодировках.

Я бы еще согласился с Вами если бы у меня вообще не было кириллицы, но она есть и все работает прекрасно, за исключением одного передача параметров в оракл идет с искажением кириллицы. Я и хочу выяснить, кто в этом виноват сам фокс или ODBC?

localhost Vch1
Кодировка WE8ISO8859P1 - это восточная европа - 8 бит.
Первые две буквы WE - Western European (западная европа)

Vch1
Кодировка устанавливается при инсталяции оракла и изменению не подлежит... Только новая инсталляция
Данный параметр определяется при создании БД Oracle, и в последующем м.б.изменён командой:
при наличии прав [sys as dba], понимания ответственности, наличия копий БД для восстановления и умения его проводить :)

В остальном Vch1 прав: хранить кириллицу в БД Oracle с такими настройками - искать приключений.

Тогда объясните мне почему на Дельфи (написал для примера на TurboDelphi то же самое), я не имею проблем с кириллицей при наличии этой неправильной кодировки?

localhostИзвини, из обсуждения так и не понял - переменная, как параметр передаётся корректно?
Другими словами, такая конструкция работает?


Делал и так ?SQLEXEC(m.IDConn,[select * from users where username=?m.lParam],...
и
lcSQLString="select * from users where username='"+m.lParam+"'"
?SQLEXEC(m.IDConn,lcSQLString,"myCurs")

все одно при просмотре в оракловском PL/SQL Developer-е запрос выглядит как
select * from users where username='??????'

Вот и думаю кто виноват фокс или ODBC ?

localhost TuchaВот и думаю кто виноват фокс или ODBC ?

1. БД Oracle с установкой NLS_LANG=WE8ISO8859P1
не предназначена для работы с кириллицей!
Обрати внимание на то,
как именно выполняет сортировку столбцов с кирилицей ваша БД Oracle.
Как следствие - не верные результаты запросов [Select Top ...] и т.д.
Т.е. - эксплуатировать базу в таком состоянии НЕЛЬЗЯ!

2. Формально работать из VFP было бы можно,
если бы ф-ция фок-са CPCONVERT позволяла
преобразование строк к кодировке 885.
Но из-за проблемы см. п.1 -
начинать разработку проекта на базе в таком состоянии НЕЛЬЗЯ!

3. Возможно некоторые инструменты (компоненты) доступа к данным,
предоставляют возможность преобразования (даже автоматическое)
строк к кодировке 885. Но из-за проблемы см. п.1 -
начинать разработку проекта на базе в таком состоянии всё равно НЕЛЬЗЯ,
даже с использованием этих инструментов.

1. В таком состоянии база эксплуатируется уже 5 лет. Сортировка, группировка выполняется без замечаний. Возможно не предназначена WE8ISO8859P1, но работает. Не я ее разрабатывал, а какая то бельгийская фирма.
2. Попробую применить CPCONVERT , не поможет придется переходить на делфи. Хотя мне фокс больше нравится.

tru55Что-то, прочтя все сообщения, так и не понял, к какой кодировке база.

Проверил и на сервере и на клиентской машине стоит AMERICAN_AMERICA.WE8ISO8859P1
Это в реестре или где?

Кодировка базы (из sqlplus)
Правда это для 9, для 8 не помню, так или нет

NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8ISO8859P1
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_NCHAR_CHARACTERSET WE8ISO8859P1
NLS_RDBMS_VERSION 8.1.7.0.0

Заботин А. Tucha , есть какие-нибудь результаты?
Выяснил что фокс не виновен. Через ADO все выходит без проблем, выходит виновен ODBC. Сейчас копаю его, но пока безрезультатно.