При доставании данных из поля типа NUMERIC как строки (т.е. как SQL_C_CHAR) в качестве десятичной точки используется ','. Библиотечная локаль стоит "С". Я так думаю драйвер ORACLE берёт локаль с запятой из реестра (в часности там есть ключик NLS_LANG с значением UKRAINIAN_UKRAINE.CL8MSWIN1251) и её то и использует при конвертировании.

Вопрос:
как узнать в какой локали происходила конвертация NUMERIC->SQL_C_CHAR независимо от драйвера, СУБД и ОС? Т.е. вариант посмотреть ключ в реестре не подходит, т.к., например, в линухе нету реестра.
Нужно мне это чтоб понять, какую локаль устанавливать, чтобы после доставания данных, корректно их конвертнуть в число с плавающей точкой (т.е. double).

Здравствуйте, Аноним, Вы писали:

А>Вопрос:
А>как узнать в какой локали происходила конвертация NUMERIC->SQL_C_CHAR независимо от драйвера, СУБД и ОС? Т.е. вариант посмотреть ключ в реестре не подходит, т.к., например, в линухе нету реестра.
А>Нужно мне это чтоб понять, какую локаль устанавливать, чтобы после доставания данных, корректно их конвертнуть в число с плавающей точкой (т.е. double).

В OCI есть функции для получения информации о локали:
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10749/ch10oci.htm#sthref1229

А почему нельзя сразу достать значение как double?

Здравствуйте, Sergey Ten, Вы писали:

ST>В OCI есть функции для получения информации о локали:
ST>http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10749/ch10oci.htm#sthref1229
Это нужно сделать в ODBC

ST>А почему нельзя сразу достать значение как double?
Дело в том, что заранее неизвесно в каком виде пользователь захочет забрать данные.

Здравствуйте, Аноним, Вы писали:

А>Это нужно сделать в ODBC

Не уверен, что такое возможно. ODBC на то и ODBC, чтобы скрывать такие специфичные для Oracle детали, как NLS_LANG.

ST>>А почему нельзя сразу достать значение как double?
А>Дело в том, что заранее неизвесно в каком виде пользователь захочет забрать данные.

Что понимается под "забрать данные"? Как ты ему отдашь, так он и заберет. Какая задача решается?

Здравствуйте, Sergey Ten, Вы писали:

ST>Здравствуйте, Аноним, Вы писали:

А>>Это нужно сделать в ODBC

ST>Не уверен, что такое возможно. ODBC на то и ODBC, чтобы скрывать такие специфичные для Oracle детали, как NLS_LANG.
Как раз потому, что ODBC скрывает специфичные вещи, это должно быть возможно. Т.е. должна быть возможность (независимо от используемой СУБД и драйвера) задать какую локаль использовать при конвертации. В этом и вопрос.
Как по мне, то логичней всего было бы чтобы драйвер смотрел, какая локаль установлена в libc, но, к сожалению, некоторые (в часности родной ораклиный под Винду) этого не делают.

ST>>>А почему нельзя сразу достать значение как double?
А>>Дело в том, что заранее неизвесно в каком виде пользователь захочет забрать данные.

ST>Что понимается под "забрать данные"? Как ты ему отдашь, так он и заберет. Какая задача решается?
Пишется объектно-ориентированная оболочка для ODBC. Интерфейс — аля jdbc.
Я вычитываю значение колонки из БД через ODBC в свой внутренний буффер, а пользователь может его забирать разными функциями getInt, getDouble, getString etc.
В доках по ODBC написано, что для колонки типа DECIMAL
преобразование по умолчанию к CHAR[]. Соответственно и во внутреннем буфере я его храню как CHAR[]. Только вот возникла проблема, что неясно какую локаль использует драйвер когда ложит данные в буфер.

Здравствуйте, KRA, Вы писали:

KRA>В доках по ODBC написано, что для колонки типа DECIMAL
KRA>преобразование по умолчанию к CHAR[]. Соответственно и во внутреннем буфере я его храню как CHAR[]. Только вот возникла проблема, что неясно какую локаль использует драйвер когда ложит данные в буфер.

Забирай как double (int, char[], ..., тот тип, что пришел с запроса) и храни как void*. А уж raw buffer потом преобразовывай как хочется. Или посмотри реализации VARIANT-а в других системах. А все держать в строке — тебе придется повторить часть кода клиентской DLL Оракла для поддержки не только чисел, но и datetime.