RE: Troubleshooting ORA-12704 errors

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Fri, 4 Oct 2019 13:58:36 -0400
Message-ID: <03a301d57add$58a46eb0$09ed4c10$_at_rsiz.com>



ah, SQLAlchemy, so python, so cx_oracle.  

Type and variable manipulation accessing Oracle via cx_oracle has in the past been troublesome and likewise trying to simulate what it does with a different client tool is problematic.  

Somewhere in the python client stack you probably have a generated cx_Oracle.connect call (which may be generated in the case of SQLAlchemy.) There is an example of all this in:

https://cx-oracle.readthedocs.io/en/latest/user_guide/globalization.html  

but without dumping the generated python and environment and so forth it would be difficult to see where the old one was going wrong. Some part of your stack was apparently updated to do correctly what it was formerly getting wrong.  

Good luck. multi-database client application tools inherently face additional challenges.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Chris Stephens Sent: Friday, October 04, 2019 8:30 AM
To: Norman Dunbar
Cc: oracle-l
Subject: Re: Troubleshooting ORA-12704 errors  

in theory that makes sense but dumping out the values passed into bind doesn't show any out of the ordinary characters. when we substitute the binds for literals with literal_binds, those literals all look like standard ascii values.  

i just got an email from the developer that the problem has disappeared after upgrading to latest version of SQLAlchemy and project specific code base.  

On Thu, Oct 3, 2019 at 3:27 PM Norman Dunbar <oracle_at_dunbar-it.co.uk> wrote:

Hi Chris,

Your columns and binds are looking like they use different and incompatible charactersets. Some charactersets cannot be compared - resulting in what you are seeing here. When you changed from varchar2 to nvarchar2 you were using the same characterset in the two sides of the comparison.

In a eord, or two, you are now comparing apples, before it was apples and oranges. You see this in the csid values in the two ora-12704 lines in your original post.

I might be wrong but usually, binds appear before the exec in the trace. From the look of things your sql is parsed then the error is detected, but it doesn't appear as a parse error line, then the cursor is closed - hard closed - so no exec and that's possiblt why the binds are missing.

Most of the ora-12704 lines are the same as the binds would be, the just have different names.

HTH Chees,
Norm.
--

Sent from my Android device with K-9 Mail. Please excuse my brevity.

--

http://www.freelists.org/webpage/oracle-l Received on Fri Oct 04 2019 - 19:58:36 CEST

Original text of this message