Also, try first solving the problem of reading from the database. So if you
have some data in a table that you know is correctly stored, try a sql query
from AOLserver, and see if you can pinpoint where it gets converted.
Once you have that sorted, writing to the database should be solvable.
From: Fenton, Brian
Sent: 19 July 2011 09:12
To: AOLserver Discussion
Subject: Re: [AOLSERVER] chinese characters and oracle driver
Also, try first solving the problem of reading from the database. So if you
have some data in a table that you know is correctly stored, try a sql query
from
I don't think it's tcl at this point. I can see that aolserver/tcl can bring
in the unicode characters and return them to the client 'as is'.
And you can see what encoding system tcl is using via this command as well:
[encoding system]
which shows that tcl is using UTF-8, which is what is
...@chickcentral.com]
Sent: 18 July 2011 16:19
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] chinese characters and oracle driver
I don't think it's tcl at this point. I can see that aolserver/tcl can bring
in the unicode characters and return them to the client 'as is'.
And you can see what encoding
I just grabbed the latest oracle driver from cvs and you are right: there is
no explicit support for either NCHAR or NVARCHAR2 - which oracle requires to
store unicode characters.
So, I will try to update the driver and report back.
Thanks
--
AOLserver - http://www.aolserver.com/
To Remove
Well, I reached an impasse. I grabbed the latest source from CVS, added
support for the 2 datatypes (NCHAR, NVARCHAR2), and recompiled. Then, I
turned on debugging for the driver.
The logs look great. The driver constructs the queries appropriately:
e.g.
Make sure that any vars set in your shell environment that relate to this are
also set in your nsd wrapper script. I wish I knew for sure if that is enough
for them to be effective, but I don't. I vaguely recall that the C API the
driver uses is called Pro-C on the Oracle side - you might
Just a quick shot in the dark here.
I have ran into encoding issues in the past because by default TCL will assume
everything is Latin-1 and it is not always straight forward when a conflict
will happen.
You can set a variable like $first_names to be a UTF-8 string and it can be
written
I've had to deal with Chinese Characters and Postgres. I don't recall all the
details anymore but I do recall what Peter is saying, that Tcl was a culprit
more than the database.
I would use sqlplus to check what myform.tcl is inserting into the database.
That will at least tell you whether
