RE: Troubleshooting ORA-12704 errors

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <cstephens16@xxxxxxxxx>, "'Norman Dunbar'" <oracle@xxxxxxxxxxxxxxx>
  • Date: Fri, 4 Oct 2019 13:58:36 -0400

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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx> 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.

Other related posts: