Error retrieving results from a table performing multiplication on column

[Moataz-E]

In python 3.5.5 running cx_Oracle 6.0b2 and connecting to Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production.

If I run a query such as:

SELECT price*100
FROM my_table

and I try to retrieve the result using fetch, python seems to fail with the error: ValueError: invalid literal for int() with base 10: '0.0157'

Does anyone know what the issue could be? If I remove the multiplication by 100 it seems to work fine without any issues.

Moataz

[cjbj]

@Moataz-E what OS are you using? What version of Oracle client libraries (e.g. Instant Client) are you using? Got a Python code snippet so we can all be testing the same code paths?

[Moataz-E]

cjbj, managed to get it fixed by using TO_BINARY_FLOAT() on the calculated number. So:

SELECT TO_BINARY_FLOAT(price*100)
FROM my_table

Thanks

[cjbj]

@Moataz-E if you can give the info I asked for (and also some data), then it will be easier for us to fix it.

[Moataz-E]

@cjbj oracle instant client 12.2.0.1.0, and running Windows 7 x64 bit. Code is a simple connection, cursor, execute sequence on the query mentioned above.

[anthony-tuininga]

@Moataz-E what is the structure of "my_table"? And the contents of one row?

[bobbydurrett]

I'm having the same problem. I'm on Windows 7 with the full 11.2.0.4 32 bit client. Using Python 3.61. I run this code:

cur.execute('select to_char(blocks/7) from user_tables')
row = cur.fetchone()
print(row)

cur.execute('select blocks/7 from user_tables')
row = cur.fetchone()
print(row)

I get this output:

('2.28571428571428571428571428571428571429',)
Traceback (most recent call last):
File "bug.py", line 12, in
row = cur.fetchone()
ValueError: invalid literal for int() with base 10: '2.28571428571428571428571428571428571429'

Seems to be running int('2.28571428571428571428571428571428571429',base=10)
Previous version of cx_Oracle just converts this to a float.

Bobby

[anthony-tuininga]

Thanks, Bobby. That was helpful. I have now replicated the issue and found a solution which I shall commit shortly, along with some tests to make sure this issue doesn't crop up again.