John,
Not sure I get what you're saying here. I'm not actually selecting
from a DB table so there's no opportunity for NCHAR.
Anyway, NCHAR is only typically for where you want to run your DB in 8
bit but have a few tables with utf-8 data. We have our whole DB in
utf-8 (which can store
Was playing with this as well and I am running into some funny stuff but I
am not sure if it is a DBD issue
Seems it might be an in compatiably between NLS_LANG and the Char you are
trying to read
Try this code again this time add the data to a NCHAR field that may help
> DBI version : 1
Hi John,
Did you make any sense of this?
Thanks,
Steve
On 30/03/2009, at 10:39 AM, Steve Baldwin wrote:
John,
In case it helps, here is a version of my test script that seems to
correctly handle utf-8 chars for bind_param_inout ...
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI qw()
John,
In case it helps, here is a version of my test script that seems to
correctly handle utf-8 chars for bind_param_inout ...
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI qw();
use DBD::Oracle qw();
use Encode;
print "Using DBI $DBI::VERSION and DBD::Oracle $DBD::Oracle::VERSION\n";
John,
I installed this version and it didn't seem to make any difference ...
stbald...@au-stb-mobile:~/dev$ ./utf8.plx
Using DBI 1.605 and DBD::Oracle 1.23
Sym (1) = €
Sym (2) = â¬
I see the same behaviour whether I connect to an 11g or 9i database. I
have the 11g oracle client.
Here's a lev
I believe this has been has been fixed in the latest trunk version of
DBD::Oracle
I ran the test below and came up with the same values. If you can test
this version of DBD::Oracle
http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-123-RC4.tar
and see if it works for you
cheers
John Scol
DBI version : 1.605
DBD::Oracle version : 1.22
Database: 11.1.0.7 (don't think this matters)
DB Charset : AL32UTF8 (this definitely matters)
NLS_LANG: AMERICAN_AMERICA.AL32UTF8
Consider the following script ...
#!/usr/bin/perl -w
use strict;
use warnings;
