Bug #83656 for DBD-Oracle: Not able to retrieve Non-Ascii character from database

Wed Feb 27 02:17:11 2013 avinashyelsangi [...] gmail.com - Ticket created

Subject:

Not able to retrieve Non-Ascii character from database

Hi Team, We are using DBI module in one of our product. Following is the sample code : #!/usr/bin/perl use strict; use DBI; my $dbh = DBI->connect("dbi:oracle:npm", "username", "password"); #my $name = "Anand"; my $name = "ranù.it1"; my $sth = $dbh->prepare("SELECT * FROM tablename WHERE name = ?"); $sth->bind_param(1, $name); $sth->execute(); my ($name, $address) = $sth->fetchrow(); print "$name $address \n"; $sth->finish(); $dbh->disconnect(); We are able to retrieve the values from tablename for name Anand (ascii character). But we are not able to retrieve the values from tablename for name "ranù.it1" (non-ascii character). Name "ranù.it1" exists in tablename . Please help us to overcome this issue. We are using below software and version for development. DBI version : 1.605 Perl Version : 5.8.8 Oracle version : 10.2.0.5 Thanks & Regards, Avinash

Wed Feb 27 02:27:25 2013 h.m.brand [...] xs4all.nl - Correspondence added

Subject:	Re: [rt.cpan.org #83656] Not able to retrieve Non-Ascii character from database
Date:	Wed, 27 Feb 2013 08:27:13 +0100
To:	bug-DBI [...] rt.cpan.org
From:	"H.Merijn Brand" <h.m.brand [...] xs4all.nl>

On Wed, 27 Feb 2013 02:17:14 -0500, "Avinash via RT" <bug-DBI@rt.cpan.org> wrote: Show quoted text

> Wed Feb 27 02:17:11 2013: Request 83656 was acted upon. > Hi Team, > > We are using DBI module in one of our product. > > Following is the sample code : > > #!/usr/bin/perl > use strict; > use DBI; > > my $dbh = DBI->connect ("dbi:oracle:npm", "username", "password"); > > #my $name = "Anand"; > my $name = "ranù.it1"; > > my $sth = $dbh->prepare ("SELECT * FROM tablename WHERE name = ?"); > $sth->bind_param (1, $name); > $sth->execute (); > > my ($name, $address) = $sth->fetchrow (); > print "$name $address \n"; > > $sth->finish (); > $dbh->disconnect (); > > We are able to retrieve the values from tablename for name Anand (ascii > character). But we are not able to retrieve the values from tablename > for name "ranù.it1" (non-ascii character). Name "ranù.it1" exists in > tablename . Please help us to overcome this issue. > > We are using below software and version for development. > > DBI version : 1.605

current version is 1.623 what is the version of DBD::Oracle? Current is 1.56 Show quoted text

> Perl Version : 5.8.8

Sufficient, but old. current is 5.16.2 Show quoted text

> Oracle version : 10.2.0.5

Sufficient But you are missing a lot of information that is VITAL to know here: • What is your current locale? • What is the database locale? • What is the session locale? • Does it fail for this name, or also for names with diacritical marks outside of the iso-8859-1 range? ( or do you expect it to be cp1252 encoding?) • Did you - on purpose - not explicitly encode/decode data? • What are - if set - CHARACTER SET, NLS_CHARACTERSET, and NLS_NCHAR_CHARACTERSET for the database? Show quoted text

sql> select * from nls_database_parameters; sql> select * from nls_session_parameters; sql> select * from nls_instance_parameters;

Show quoted text

> Thanks & Regards, > Avinash

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

Wed Feb 27 02:27:27 2013 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 27 06:53:21 2013 avinashyelsangi [...] gmail.com - Correspondence added

CC:	arunkumar.ananthanarayanan [...] wipro.com, avinashyelsangi [...] wipro.com, ganesh.shetty [...] wipro.com, ganga.reddi [...] wipro.com, periyasamy.palanisamy [...] ericsson.com, tajammul.pasha [...] wipro.com, TIMB [...] cpan.org
Subject:	Re: [rt.cpan.org #83656] Not able to retrieve Non-Ascii character from database
Date:	Wed, 27 Feb 2013 17:23:04 +0530
To:	bug-DBI [...] rt.cpan.org
From:	avinash yelsangi <avinashyelsangi [...] gmail.com>

Hi Team, Please find below queries clarification: • What is your current locale? bash-3.00# locale LANG= LC_CTYPE=en_CA.ISO8859-1 LC_NUMERIC=en_CA.ISO8859-1 LC_TIME=en_CA.ISO8859-1 LC_COLLATE=en_CA.ISO8859-1 LC_MONETARY=en_CA.ISO8859-1 LC_MESSAGES=C LC_ALL= • What is the database locale? bash-3.00# echo $LNS_LANG • Does it fail for this name, or also for names with diacritical marks outside of the iso-8859-1 range? ( or do you expect it to be cp1252 encoding?) It will fail for every user which contains diacritical marks(ù). It is inside iso-8859-1 encoding range. • Did you - on purpose - not explicitly encode/decode data? We are not doing any encoding/decoding. • What are - if set - CHARACTER SET, NLS_CHARACTERSET, and NLS_NCHAR_CHARACTERSET for the database? Show quoted text

sql> select * from nls_database_parameters; sql> select * from nls_session_parameters; sql> select * from nls_instance_parameters;

sql > select * from nls_database_parameters NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CHARACTERSET UTF8 NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH.MI.SSXFF AM NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_RDBMS_VERSION 10.2.0.5.0 sql > select * from nls_session_parameters; NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH.MI.SSXFF AM NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE sql > select * from nls_instance_parameters; NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_SORT NLS_DATE_LANGUAGE NLS_DATE_FORMAT NLS_CURRENCY NLS_NUMERIC_CHARACTERS NLS_ISO_CURRENCY NLS_CALENDAR NLS_TIME_FORMAT NLS_TIMESTAMP_FORMAT NLS_TIME_TZ_FORMAT NLS_TIMESTAMP_TZ_FORMAT NLS_DUAL_CURRENCY NLS_COMP NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE Thanks & Regards, Avinash On Wed, Feb 27, 2013 at 12:57 PM, h.m.brand@xs4all.nl via RT < bug-DBI@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=83656 > > > On Wed, 27 Feb 2013 02:17:14 -0500, "Avinash via RT" > <bug-DBI@rt.cpan.org> wrote: >

> > Wed Feb 27 02:17:11 2013: Request 83656 was acted upon. > > Hi Team, > > > > We are using DBI module in one of our product. > > > > Following is the sample code : > > > > #!/usr/bin/perl > > use strict; > > use DBI; > > > > my $dbh = DBI->connect ("dbi:oracle:npm", "username", "password"); > > > > #my $name = "Anand"; > > my $name = "ranù.it1"; > > > > my $sth = $dbh->prepare ("SELECT * FROM tablename WHERE name = ?"); > > $sth->bind_param (1, $name); > > $sth->execute (); > > > > my ($name, $address) = $sth->fetchrow (); > > print "$name $address \n"; > > > > $sth->finish (); > > $dbh->disconnect (); > > > > We are able to retrieve the values from tablename for name Anand (ascii > > character). But we are not able to retrieve the values from tablename > > for name "ranù.it1" (non-ascii character). Name "ranù.it1" exists in > > tablename . Please help us to overcome this issue. > > > > We are using below software and version for development. > > > > DBI version : 1.605

> > current version is 1.623 > > what is the version of DBD::Oracle? Current is 1.56 >

> > Perl Version : 5.8.8

> > Sufficient, but old. current is 5.16.2 >

> > Oracle version : 10.2.0.5

> > Sufficient > > But you are missing a lot of information that is VITAL to know here: > > • What is your current locale? > • What is the database locale? > • What is the session locale? > • Does it fail for this name, or also for names with diacritical marks > outside of the iso-8859-1 range? ( or do you expect it to be cp1252 > encoding?) > • Did you - on purpose - not explicitly encode/decode data? > > • What are - if set - CHARACTER SET, NLS_CHARACTERSET, and > NLS_NCHAR_CHARACTERSET for the database? >

> sql> select * from nls_database_parameters; > sql> select * from nls_session_parameters; > sql> select * from nls_instance_parameters;

>

> > Thanks & Regards, > > Avinash

> > -- > H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ > using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE > http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ > http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ > >

Wed Feb 27 07:20:57 2013 h.m.brand [...] xs4all.nl - Correspondence added

Subject:	Re: [rt.cpan.org #83656] Not able to retrieve Non-Ascii character from database
Date:	Wed, 27 Feb 2013 13:20:39 +0100
To:	bug-DBI [...] rt.cpan.org
From:	"H.Merijn Brand" <h.m.brand [...] xs4all.nl>

On Wed, 27 Feb 2013 06:53:23 -0500, "Avinash via RT" <bug-DBI@rt.cpan.org> wrote: Show quoted text

> Please find below queries clarification: > > • What is your current locale? > > bash-3.00# locale > LANG= > LC_CTYPE=en_CA.ISO8859-1

^^^^^^^^^^^^^^^ Show quoted text

> LC_NUMERIC=en_CA.ISO8859-1 > LC_TIME=en_CA.ISO8859-1 > LC_COLLATE=en_CA.ISO8859-1 > LC_MONETARY=en_CA.ISO8859-1 > LC_MESSAGES=C > LC_ALL= > > • What is the database locale? > > bash-3.00# echo $LNS_LANG > > > • Does it fail for this name, or also for names with diacritical marks > outside of the iso-8859-1 range? ( or do you expect it to be cp1252 > encoding?) > > It will fail for every user which contains diacritical marks(ù). It is > inside iso-8859-1 encoding range.

Which is what I expect. I also expect it to PASS for all diacriticals *outside* the iso-8859-1 range, like Paveł Show quoted text

> • Did you - on purpose - not explicitly encode/decode data? > > We are not doing any encoding/decoding.

Well, you should. Oracle expects UTF-8, and you pass it iso-8859-1 Start reading http://search.cpan.org/~pythian/DBD-Oracle-1.56/lib/DBD/Oracle.pm#UNICODE Anyway, IMHO this is NOT a DBI bug. This is either something already fixed in newer releases of DBI/DBD::Oracle or an oversight in your scripts Show quoted text

> • What are - if set - CHARACTER SET, NLS_CHARACTERSET, and > NLS_NCHAR_CHARACTERSET for the database? >

> sql> select * from nls_database_parameters; > sql> select * from nls_session_parameters; > sql> select * from nls_instance_parameters;

> > sql > select * from nls_database_parameters > > NLS_LANGUAGE AMERICAN > NLS_TERRITORY AMERICA > NLS_CURRENCY $ > NLS_ISO_CURRENCY AMERICA > NLS_NUMERIC_CHARACTERS ., > NLS_CHARACTERSET UTF8

^^^^ Show quoted text

> NLS_CALENDAR GREGORIAN > NLS_DATE_FORMAT DD-MON-RR > NLS_DATE_LANGUAGE AMERICAN > NLS_SORT BINARY > NLS_TIME_FORMAT HH.MI.SSXFF AM > NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM > NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR > NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR > NLS_DUAL_CURRENCY $ > NLS_COMP BINARY > NLS_LENGTH_SEMANTICS BYTE > NLS_NCHAR_CONV_EXCP FALSE > NLS_NCHAR_CHARACTERSET AL16UTF16 > NLS_RDBMS_VERSION 10.2.0.5.0 > > sql > select * from nls_session_parameters; > > NLS_LANGUAGE AMERICAN > NLS_TERRITORY AMERICA > NLS_CURRENCY $ > NLS_ISO_CURRENCY AMERICA > NLS_NUMERIC_CHARACTERS ., > NLS_CALENDAR GREGORIAN > NLS_DATE_FORMAT DD-MON-RR > NLS_DATE_LANGUAGE AMERICAN > NLS_SORT BINARY > NLS_TIME_FORMAT HH.MI.SSXFF AM > NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM > NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR > NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR > NLS_DUAL_CURRENCY $ > NLS_COMP BINARY > NLS_LENGTH_SEMANTICS BYTE > NLS_NCHAR_CONV_EXCP FALSE > > sql > select * from nls_instance_parameters; > NLS_LANGUAGE AMERICAN > NLS_TERRITORY AMERICA > NLS_SORT > NLS_DATE_LANGUAGE > NLS_DATE_FORMAT > NLS_CURRENCY > NLS_NUMERIC_CHARACTERS > NLS_ISO_CURRENCY > NLS_CALENDAR > NLS_TIME_FORMAT > NLS_TIMESTAMP_FORMAT > NLS_TIME_TZ_FORMAT > NLS_TIMESTAMP_TZ_FORMAT > NLS_DUAL_CURRENCY > NLS_COMP > NLS_LENGTH_SEMANTICS BYTE > NLS_NCHAR_CONV_EXCP FALSE > > > Thanks & Regards, > Avinash

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

Wed Feb 27 09:31:44 2013 HMBRAND [...] cpan.org - Broken in 1.605 deleted

Wed Feb 27 09:31:44 2013 HMBRAND [...] cpan.org - Correspondence added

Moved to DBD::Oracle

Wed Feb 27 09:31:46 2013 HMBRAND [...] cpan.org - Queue changed from DBI to DBD-Oracle

Fri Mar 01 08:45:27 2013 avinashyelsangi [...] gmail.com - Correspondence added

CC:	arunkumar.ananthanarayanan [...] wipro.com, avinashyelsangi [...] wipro.com, ganesh.shetty [...] wipro.com, ganga.reddi [...] wipro.com, periyasamy.palanisamy [...] ericsson.com, tajammul.pasha [...] wipro.com, TIMB [...] cpan.org
Subject:	Re: [rt.cpan.org #83656] Not able to retrieve Non-Ascii character from database
Date:	Fri, 1 Mar 2013 19:15:12 +0530
To:	bug-DBI [...] rt.cpan.org
From:	avinash yelsangi <avinashyelsangi [...] gmail.com>

Hi Team, Our client is escalating on the mentioned raised ticket. Can you please provide us any solution or workaround the raised ticket as soon as possible. I mean to say how can I fix the mentioned problem in raised ticket(83656 <https://rt.cpan.org/Ticket/Display.html?id=83656>). Thanks & Regards, Avinash <URL: https://rt.cpan.org/Ticket/Display.html?id=83656 > On Wed, 27 Feb 2013 06:53:23 -0500, "Avinash via RT" <bug-DBI@rt.cpan.org> wrote: Show quoted text

> Please find below queries clarification: > > • What is your current locale? > > bash-3.00# locale > LANG= > LC_CTYPE=en_CA.ISO8859-1

^^^^^^^^^^^^^^^ Show quoted text

> LC_NUMERIC=en_CA.ISO8859-1 > LC_TIME=en_CA.ISO8859-1 > LC_COLLATE=

On Wed, Feb 27, 2013 at 5:50 PM, h.m.brand@xs4all.nl via RT < bug-DBI@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=83656 > > > On Wed, 27 Feb 2013 06:53:23 -0500, "Avinash via RT" > <bug-DBI@rt.cpan.org> wrote: >

> > Please find below queries clarification: > > > > • What is your current locale? > > > > bash-3.00# locale > > LANG= > > LC_CTYPE=en_CA.ISO8859-1

> ^^^^^^^^^^^^^^^ >

> > LC_NUMERIC=en_CA.ISO8859-1 > > LC_TIME=en_CA.ISO8859-1 > > LC_COLLATE=en_CA.ISO8859-1 > > LC_MONETARY=en_CA.ISO8859-1 > > LC_MESSAGES=C > > LC_ALL= > > > > • What is the database locale? > > > > bash-3.00# echo $LNS_LANG > > > > > > • Does it fail for this name, or also for names with diacritical marks > > outside of the iso-8859-1 range? ( or do you expect it to be cp1252 > > encoding?) > > > > It will fail for every user which contains diacritical marks(ù). It is > > inside iso-8859-1 encoding range.

> > Which is what I expect. I also expect it to PASS for all diacriticals > *outside* the iso-8859-1 range, like Paveł >

> > • Did you - on purpose - not explicitly encode/decode data? > > > > We are not doing any encoding/decoding.

> > Well, you should. Oracle expects UTF-8, and you pass it iso-8859-1 > > Start reading > http://search.cpan.org/~pythian/DBD-Oracle-1.56/lib/DBD/Oracle.pm#UNICODE > > Anyway, IMHO this is NOT a DBI bug. This is either something already > fixed in newer releases of DBI/DBD::Oracle or an oversight in your > scripts >

> > • What are - if set - CHARACTER SET, NLS_CHARACTERSET, and > > NLS_NCHAR_CHARACTERSET for the database? > >

> > sql> select * from nls_database_parameters; > > sql> select * from nls_session_parameters; > > sql> select * from nls_instance_parameters;

> > > > sql > select * from nls_database_parameters > > > > NLS_LANGUAGE AMERICAN > > NLS_TERRITORY AMERICA > > NLS_CURRENCY $ > > NLS_ISO_CURRENCY AMERICA > > NLS_NUMERIC_CHARACTERS ., > > NLS_CHARACTERSET UTF8

> ^^^^ >

> > NLS_CALENDAR GREGORIAN > > NLS_DATE_FORMAT DD-MON-RR > > NLS_DATE_LANGUAGE AMERICAN > > NLS_SORT BINARY > > NLS_TIME_FORMAT HH.MI.SSXFF AM > > NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM > > NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR > > NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR > > NLS_DUAL_CURRENCY $ > > NLS_COMP BINARY > > NLS_LENGTH_SEMANTICS BYTE > > NLS_NCHAR_CONV_EXCP FALSE > > NLS_NCHAR_CHARACTERSET AL16UTF16 > > NLS_RDBMS_VERSION 10.2.0.5.0 > > > > sql > select * from nls_session_parameters; > > > > NLS_LANGUAGE AMERICAN > > NLS_TERRITORY AMERICA > > NLS_CURRENCY $ > > NLS_ISO_CURRENCY AMERICA > > NLS_NUMERIC_CHARACTERS ., > > NLS_CALENDAR GREGORIAN > > NLS_DATE_FORMAT DD-MON-RR > > NLS_DATE_LANGUAGE AMERICAN > > NLS_SORT BINARY > > NLS_TIME_FORMAT HH.MI.SSXFF AM > > NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM > > NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR > > NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR > > NLS_DUAL_CURRENCY $ > > NLS_COMP BINARY > > NLS_LENGTH_SEMANTICS BYTE > > NLS_NCHAR_CONV_EXCP FALSE > > > > sql > select * from nls_instance_parameters; > > NLS_LANGUAGE AMERICAN > > NLS_TERRITORY AMERICA > > NLS_SORT > > NLS_DATE_LANGUAGE > > NLS_DATE_FORMAT > > NLS_CURRENCY > > NLS_NUMERIC_CHARACTERS > > NLS_ISO_CURRENCY > > NLS_CALENDAR > > NLS_TIME_FORMAT > > NLS_TIMESTAMP_FORMAT > > NLS_TIME_TZ_FORMAT > > NLS_TIMESTAMP_TZ_FORMAT > > NLS_DUAL_CURRENCY > > NLS_COMP > > NLS_LENGTH_SEMANTICS BYTE > > NLS_NCHAR_CONV_EXCP FALSE > > > > > > Thanks & Regards, > > Avinash

> > > -- > H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ > using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE > http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ > http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ > >

Mon Mar 04 23:21:36 2013 avinashyelsangi [...] gmail.com - Correspondence added

CC:	arunkumar.ananthanarayanan [...] wipro.com, avinashyelsangi [...] wipro.com, ganesh.shetty [...] wipro.com, ganga.reddi [...] wipro.com, periyasamy.palanisamy [...] ericsson.com, tajammul.pasha [...] wipro.com, TIMB [...] cpan.org
Subject:	Re: [rt.cpan.org #83656] Not able to retrieve Non-Ascii character from database
Date:	Tue, 5 Mar 2013 09:51:19 +0530
To:	bug-DBI [...] rt.cpan.org
From:	avinash yelsangi <avinashyelsangi [...] gmail.com>

Hi Team, Is there any update on below query. Its blocking our work.Client is escalating. Thanks & Regards, Avinash On Fri, Mar 1, 2013 at 7:15 PM, avinash yelsangi <avinashyelsangi@gmail.com>wrote: Show quoted text

> Hi Team, > > Our client is escalating on the mentioned raised ticket. > > Can you please provide us any solution or workaround the raised ticket as > soon as possible. I mean to say how can I fix the mentioned problem in > raised ticket(83656 <https://rt.cpan.org/Ticket/Display.html?id=83656>). > > Thanks & Regards, > Avinash > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=83656 > > > On Wed, 27 Feb 2013 06:53:23 -0500, "Avinash via RT" > <bug-DBI@rt.cpan.org> wrote: >

> > Please find below queries clarification: > > > > • What is your current locale? > > > > bash-3.00# locale > > LANG= > > LC_CTYPE=en_CA.ISO8859-1

> ^^^^^^^^^^^^^^^ >

> > LC_NUMERIC=en_CA.ISO8859-1 > > LC_TIME=en_CA.ISO8859-1 > > LC_COLLATE=

> > > > > On Wed, Feb 27, 2013 at 5:50 PM, h.m.brand@xs4all.nl via RT < > bug-DBI@rt.cpan.org> wrote: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=83656 > >> >> On Wed, 27 Feb 2013 06:53:23 -0500, "Avinash via RT" >> <bug-DBI@rt.cpan.org> wrote: >>

>> > Please find below queries clarification: >> > >> > • What is your current locale? >> > >> > bash-3.00# locale >> > LANG= >> > LC_CTYPE=en_CA.ISO8859-1

>> ^^^^^^^^^^^^^^^ >>

>> > LC_NUMERIC=en_CA.ISO8859-1 >> > LC_TIME=en_CA.ISO8859-1 >> > LC_COLLATE=en_CA.ISO8859-1 >> > LC_MONETARY=en_CA.ISO8859-1 >> > LC_MESSAGES=C >> > LC_ALL= >> > >> > • What is the database locale? >> > >> > bash-3.00# echo $LNS_LANG >> > >> > >> > • Does it fail for this name, or also for names with diacritical marks >> > outside of the iso-8859-1 range? ( or do you expect it to be cp1252 >> > encoding?) >> > >> > It will fail for every user which contains diacritical marks(ù). It is >> > inside iso-8859-1 encoding range.

>> >> Which is what I expect. I also expect it to PASS for all diacriticals >> *outside* the iso-8859-1 range, like Paveł >>

>> > • Did you - on purpose - not explicitly encode/decode data? >> > >> > We are not doing any encoding/decoding.

>> >> Well, you should. Oracle expects UTF-8, and you pass it iso-8859-1 >> >> Start reading >> http://search.cpan.org/~pythian/DBD-Oracle-1.56/lib/DBD/Oracle.pm#UNICODE >> >> Anyway, IMHO this is NOT a DBI bug. This is either something already >> fixed in newer releases of DBI/DBD::Oracle or an oversight in your >> scripts >>

>> > • What are - if set - CHARACTER SET, NLS_CHARACTERSET, and >> > NLS_NCHAR_CHARACTERSET for the database? >> >

>> > sql> select * from nls_database_parameters; >> > sql> select * from nls_session_parameters; >> > sql> select * from nls_instance_parameters;

>> > >> > sql > select * from nls_database_parameters >> > >> > NLS_LANGUAGE AMERICAN >> > NLS_TERRITORY AMERICA >> > NLS_CURRENCY $ >> > NLS_ISO_CURRENCY AMERICA >> > NLS_NUMERIC_CHARACTERS ., >> > NLS_CHARACTERSET UTF8

>> ^^^^ >>

>> > NLS_CALENDAR GREGORIAN >> > NLS_DATE_FORMAT DD-MON-RR >> > NLS_DATE_LANGUAGE AMERICAN >> > NLS_SORT BINARY >> > NLS_TIME_FORMAT HH.MI.SSXFF AM >> > NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM >> > NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR >> > NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR >> > NLS_DUAL_CURRENCY $ >> > NLS_COMP BINARY >> > NLS_LENGTH_SEMANTICS BYTE >> > NLS_NCHAR_CONV_EXCP FALSE >> > NLS_NCHAR_CHARACTERSET AL16UTF16 >> > NLS_RDBMS_VERSION 10.2.0.5.0 >> > >> > sql > select * from nls_session_parameters; >> > >> > NLS_LANGUAGE AMERICAN >> > NLS_TERRITORY AMERICA >> > NLS_CURRENCY $ >> > NLS_ISO_CURRENCY AMERICA >> > NLS_NUMERIC_CHARACTERS ., >> > NLS_CALENDAR GREGORIAN >> > NLS_DATE_FORMAT DD-MON-RR >> > NLS_DATE_LANGUAGE AMERICAN >> > NLS_SORT BINARY >> > NLS_TIME_FORMAT HH.MI.SSXFF AM >> > NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM >> > NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR >> > NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR >> > NLS_DUAL_CURRENCY $ >> > NLS_COMP BINARY >> > NLS_LENGTH_SEMANTICS BYTE >> > NLS_NCHAR_CONV_EXCP FALSE >> > >> > sql > select * from nls_instance_parameters; >> > NLS_LANGUAGE AMERICAN >> > NLS_TERRITORY AMERICA >> > NLS_SORT >> > NLS_DATE_LANGUAGE >> > NLS_DATE_FORMAT >> > NLS_CURRENCY >> > NLS_NUMERIC_CHARACTERS >> > NLS_ISO_CURRENCY >> > NLS_CALENDAR >> > NLS_TIME_FORMAT >> > NLS_TIMESTAMP_FORMAT >> > NLS_TIME_TZ_FORMAT >> > NLS_TIMESTAMP_TZ_FORMAT >> > NLS_DUAL_CURRENCY >> > NLS_COMP >> > NLS_LENGTH_SEMANTICS BYTE >> > NLS_NCHAR_CONV_EXCP FALSE >> > >> > >> > Thanks & Regards, >> > Avinash

>> >> >> -- >> H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ >> using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE >> http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ >> http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ >> >>

>

Mon May 26 16:07:23 2014 champoux [...] pythian.com - Status changed from 'open' to 'rejected'

Bug #83656 for DBD-Oracle: Not able to retrieve Non-Ascii character from database

Preferred bug tracker