Re: [cx-oracle-users] Problem with cx_Oracle 5.0.4 and Unicode support for Oracle 10g

[W. C. T. <cra...@gm...>]

Further information:

I checked the documentation for
OCINumberToText()<http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci18map003.htm#sthref4703>and
it referred me to
TO_NUMBER()<http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/functions191.htm>.
The call to OCINumberToText is passing in g_ShortNumberToStringFormatObj,
which is set to 'TM9'.  When I used sqlplus to run some tests, I discovered
that while Oracle is fine with SELECT TO_NUMBER ( '1' ) FROM DUAL, it
becomes most unhappy when you try SELECT TO_NUMBER( '1', 'TM9' ) FROM DUAL,
responding with ORA-01722: invalid number.  On the other hand, SELECT
TO_CHAR( '1', 'TM9' ) FROM DUAL works just fine.

It would appear that Oracle 10g does NOT like the 'TM9' conversion () for
numbers.

- Craig -

On Wed, Sep 22, 2010 at 16:58, W. Craig Trader <cra...@gm...>wrote:

> Additional information:
>
> When I look at the error context of the exception, the message is:
>
> in NumberVar_GetValue(): as string
>
> Which implies that the failure is in the call to OCINumberToText() at line
> 535 of NumberVar.c.
>
> - Craig -
>
>
> On Wed, Sep 22, 2010 at 14:15, W. Craig Trader <cra...@gm...>wrote:
>
>> I'm trying to use cx_Oracle 5.0.4 on 64-bit RedHat EL 5.5 / CentOS 5.5)
>> with Python 2.6 and Oracle 10g (client libraries 10.2.0).
>>
>> When I build cx_Oracle without Unicode support, it all works as expected.
>> When I build cx_Oracle *with* Unicode support, attempting to use a query
>> that returns a numeric value (such as):
>>
>> con = Connection( ... )
>> cur = con.cursor()
>> cur.execute( 'SELECT 1 FROM DUAL' )
>> rows = cur.fetchall()
>>
>>  results in this exception:
>>
>> cx_Oracle.DatabaseError: OCI-22061: invalid format text [T
>>
>> I've tried the SourceForge RPMs and I've tried installing from the source
>> tar, and the results are consistent -- without Unicode works, with Unicode
>> fails.
>>
>> All help will be greatfully appreciated.
>>
>> - Craig -
>>
>>
>