Closed mauropagano closed 5 years ago
Looks intriguing. I'll look into it and get back to you on this. What version of Python are you using?
Reproduces in both 3.5 and 3.7(.0)
Excellent. Thanks.
I have uncovered the source of the issue. This will be corrected in ODPI-C where this wasn't being handled properly.
This was addressed in cx_Oracle 7.1.2 which was just released.
Answer the following questions:
What is your version of Python? Is it 32-bit or 64-bit? -> 64-bit
What is your cx_Oracle version? -> 7.1.1
What error(s) you are seeing? -> No error raised by cx_Oracle
What OS (and version) is Python executing on? -> Linux and MacOS
What is your version of the Oracle client (e.g. Instant Client)? How was it installed? Where is it installed? 12.2.0.1, both as instant client in MacOS or full client install in Linux
What is your Oracle Database version? 12.2.0.1
What is the
PATH
environment variable (on Windows) orLD_LIBRARY_PATH
(on Linux) set to? On macOS, what is in~/lib
? -> to Oracle client libWhat Oracle environment variables did you set? How exactly did you set them? -> "classic ones" (ORACLE_HOME, ORACLE_SID, LD_LIBRARY_PATH and PATH)
Do you have a small, single Python script that immediately runs to show us the problem? -> Yes, testcase below
and in database you'll see a non printable character that even changes value internally if you execute the insert multiple times (especially across sessions)
the problem seems to be related to the way the value is bind-ed, passing the whole insert as string or just inserting the row from SQL*Plus the value is correctly stored as "0". No difference if target table has a NUMBER or FLOAT column, same problem. Also using executemany() passing a list with a single element exposes the same problem.