Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 68173
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: Nobody in particular
Requestors: tim.vanholder [...] anubex.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [1.28] Major problem with ORA_VARCHAR2 inout parameters on Oracle 11
Date: Fri, 13 May 2011 13:52:04 +0200
To: bug-DBD-Oracle [...] rt.cpan.org
From: Tim Van Holder <tim.vanholder [...] anubex.com>
Download (untitled) / with headers
text/plain 1.1k
Problem seen in: - 64-bit DBD::Oracle 1.27 as supplied by ActiveState PPM - 32-bit DBD::Oracle 1.27 as supplied by ActiveState PPM - 32-bit DBD::Oracle 1.28 as built via the CPAN module on ActiveState Perl Code has: my $sth = $dbh->prepare("BEGIN :filename := mypackage.myfunc; END;"); return unless $sth; my $filename; $sth->bind_param_inout(':filename', \$filename, 4000, ORA_VARCHAR2) or return; $sth->execute() or return; $filename =~ s/\s+$// if defined $filename; # strip trailing spaces return $filename; This code triggers no warnings or errors whatsoever, but $filename ends up completely blank. Use of dbms_output shows that a value is returned properly by the package functions - it is the binding itself that seemed to be (silently) failing. Using SQL_VARCHAR instead of ORA_VARCHAR2 works, so we have a viable workaround, but it is not exactly nice to have behaviour silently failing like this. ORA_NUMBER inout parameters do work as expected. I'm currently assuming this to be an Oracle 11 issue; I have not yet been able to test the behaviour on a non-Windows platform with Oracle 11 client, so it _may_ be Windows-specific too.
Download (untitled) / with headers
text/plain 1.8k
On Fri May 13 07:56:29 2011, tim.vanholder@anubex.com wrote: Show quoted text
> Problem seen in: > - 64-bit DBD::Oracle 1.27 as supplied by ActiveState PPM > - 32-bit DBD::Oracle 1.27 as supplied by ActiveState PPM > - 32-bit DBD::Oracle 1.28 as built via the CPAN module on > ActiveState Perl > > Code has: > > my $sth = $dbh->prepare("BEGIN :filename := mypackage.myfunc;
END;"); Show quoted text
> return unless $sth; > my $filename; > $sth->bind_param_inout(':filename', \$filename, 4000, ORA_VARCHAR2) > or return; > $sth->execute() or return; > $filename =~ s/\s+$// if defined $filename; # strip trailing spaces > return $filename; > > This code triggers no warnings or errors whatsoever, but $filename
ends Show quoted text
> up completely blank. Use of dbms_output shows that a value is returned > properly by the package functions - it is the binding itself that
seemed Show quoted text
> to be (silently) failing. > Using SQL_VARCHAR instead of ORA_VARCHAR2 works, so we have a viable > workaround, but it is not exactly nice to have behaviour silently > failing like this. > ORA_NUMBER inout parameters do work as expected. > > I'm currently assuming this to be an Oracle 11 issue; I have not yet > been able to test the behaviour on a non-Windows platform with Oracle
11 Show quoted text
> client, so it _may_ be Windows-specific too.
Works for me fine with: perl -le 'use DBI; my $h = DBI- Show quoted text
>connect("dbi:Oracle:host=xxx;sid=xxx","xxx","xxx");my $s = $h- >prepare(q{begin ? := mypkg.f_encryptString(?,?); end;});$s- >bind_param_inout(1, \my $string, 4000, {TYPE => ORA_VARCHAR2}); $s- >bind_param(2, "fredfredfred");$s->bind_param(3, "fredfredfred");$s- >execute; print $string;'
Where f_encryptString takes 2 VARCHAR2s and returns a VARCHAR2. This is to Oracle 11 with the latest Oracle Instant Client for Linux. What does mypackage.myfunc look like? Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68173] [1.28] Major problem with ORA_VARCHAR2 inout parameters on Oracle 11
Date: Wed, 18 May 2011 12:49:15 +0200
To: bug-DBD-Oracle [...] rt.cpan.org
From: Tim Van Holder <tim.vanholder [...] anubex.com>
I did some follow-up tests. These work: perl -le ' use DBI; my $v; my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); $s->bind_param_inout('myparam', \$v, 4000, { TYPE => ORA_VARCHAR2 }); $s-> execute; print "result: [$v]\n"; ' perl -le ' use DBI; use DBD::Oracle qw(:ora_types); my $v; my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); $s->bind_param_inout('myparam', \$v, 4000, { TYPE => 'ORA_VARCHAR2' }); $s-> execute; print "result: [$v]\n"; ' (reporting [Hello World]), but these do not: perl -le ' use DBI; use DBD::Oracle qw(:ora_types); my $v; my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); $s->bind_param_inout('myparam', \$v, 4000, ORA_VARCHAR2); $s-> execute; print "result: [$v]\n"; ' perl -le ' use DBI; use DBD::Oracle qw(:ora_types); my $v; my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); $s->bind_param_inout('myparam', \$v, 4000, { TYPE => ORA_VARCHAR2 }); $s-> execute; print "result: [$v]\n"; ' (reporting [<lots of spaces>]). So the ORA_VARCHAR2 does not seem to be processed correctly if it comes from DBD::Oracle's exported values (is it being treated as CHAR instead of VARCHAR2?). Then I found that I did not get the same issue with the same code/versions against a different database - and both databases are the same Oracle version too. Further tests showed that the results were identical even on an old debian box with an Oracle 10.2 client and an old DBD::Oracle (1.19 I think). Turns out this was cause by the database's NLS character set (the "failing" database has AL32UTF8 where the "working" one has "WE8MSWIN1252"). Setting NLS_LANG causes same results as with the non-UTF8 database (space-padded "Hello World"). This still does not (to me) explain why: - I do get a value when using SQL_VARCHAR or a ORA_VARCHAR2 as a string - I get space-padded results when ORA_VARCHAR2 is used as an import from DBD::Oracle On 13/05/2011 14:18, Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68173 > > > On Fri May 13 07:56:29 2011, tim.vanholder@anubex.com wrote:
>> Problem seen in: >> - 64-bit DBD::Oracle 1.27 as supplied by ActiveState PPM >> - 32-bit DBD::Oracle 1.27 as supplied by ActiveState PPM >> - 32-bit DBD::Oracle 1.28 as built via the CPAN module on >> ActiveState Perl >> >> Code has: >> >> my $sth = $dbh->prepare("BEGIN :filename := mypackage.myfunc;
> END;");
>> return unless $sth; >> my $filename; >> $sth->bind_param_inout(':filename', \$filename, 4000, ORA_VARCHAR2) >> or return; >> $sth->execute() or return; >> $filename =~ s/\s+$// if defined $filename; # strip trailing spaces >> return $filename; >> >> This code triggers no warnings or errors whatsoever, but $filename
> ends
>> up completely blank. Use of dbms_output shows that a value is returned >> properly by the package functions - it is the binding itself that
> seemed
>> to be (silently) failing. >> Using SQL_VARCHAR instead of ORA_VARCHAR2 works, so we have a viable >> workaround, but it is not exactly nice to have behaviour silently >> failing like this. >> ORA_NUMBER inout parameters do work as expected. >> >> I'm currently assuming this to be an Oracle 11 issue; I have not yet >> been able to test the behaviour on a non-Windows platform with Oracle
> 11
>> client, so it _may_ be Windows-specific too.
> > Works for me fine with: > > perl -le 'use DBI; my $h = DBI-
>> connect("dbi:Oracle:host=xxx;sid=xxx","xxx","xxx");my $s = $h- >> prepare(q{begin ? := mypkg.f_encryptString(?,?); end;});$s- >> bind_param_inout(1, \my $string, 4000, {TYPE => ORA_VARCHAR2}); $s- >> bind_param(2, "fredfredfred");$s->bind_param(3, "fredfredfred");$s- >> execute; print $string;'
> > Where f_encryptString takes 2 VARCHAR2s and returns a VARCHAR2. This is > to Oracle 11 with the latest Oracle Instant Client for Linux. > > What does mypackage.myfunc look like? > > Martin
Download (untitled) / with headers
text/plain 4.1k
On Wed May 18 06:53:40 2011, tim.vanholder@anubex.com wrote: Show quoted text
> I did some follow-up tests. > > These work:
OK, we are both guilty of not using strict and warnings: BTW, your examples don't work for me. I get "Can't bind unknown placeholder 'myparam'" presumably because that should be ":myparam" in the bind_param_inout call. Show quoted text
> perl -le ' > use DBI; > my $v; > my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); > my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); > $s->bind_param_inout('myparam', \$v, 4000, { TYPE => ORA_VARCHAR2 }); > $s-> execute; > print "result: [$v]\n"; > '
If you add strict you'll see Bareword "ORA_VARCHAR2" not allowed while "strict subs" in use I'm not sure right now what TYPE gets set to if you use ORA_VARCHAR2 without importing it first (probably 0 which probably causes DBD::Oracle to use the default type). The following one should say: Argument "ORA_VARCHAR2" isn't numeric It needs to be numeric not a string 'ORA_VARCHAR2'. However because you have not got strict or warnings enabled you do not see that and I guess the default type is chosen. Always use strict and warnings when you get strange results. Show quoted text
> perl -le ' > use DBI; > use DBD::Oracle qw(:ora_types); > my $v; > my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); > my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); > $s->bind_param_inout('myparam', \$v, 4000, { TYPE => 'ORA_VARCHAR2'
}); Show quoted text
> $s-> execute; > print "result: [$v]\n"; > '
Show quoted text
> > (reporting [Hello World]), but these do not: > perl -le ' > use DBI; > use DBD::Oracle qw(:ora_types); > my $v; > my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); > my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); > $s->bind_param_inout('myparam', \$v, 4000, ORA_VARCHAR2); > $s-> execute; > print "result: [$v]\n"; > '
The above one is correct systax and uses ORA_VARCHAR2. Like you I get a large string of what appears to be spaces. Show quoted text
> perl -le ' > use DBI; > use DBD::Oracle qw(:ora_types); > my $v; > my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); > my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); > $s->bind_param_inout('myparam', \$v, 4000, { TYPE => ORA_VARCHAR2 }); > $s-> execute; > print "result: [$v]\n"; > '
The above one is also correct syntax etc and I believe uses ORA_VARCHAR2. Show quoted text
> (reporting [<lots of spaces>]).
You missed out the {ora_type => ORA_VARCHAR2} which I believe is the correct way to do it. Bare in mind some notes in the pod about different string padding behaviour - search for ORA_VARCHAR2. Here are some excerpts: ORA_VARCHAR2 Oracle clients using OCI 8 will strip trailing spaces and allow embedded \0 bytes. Oracle clients using OCI 9.2 do not strip trailing spaces and allow embedded \0 bytes. This is the normal default placeholder type. Padded Char Fields Oracle Clients after OCI 9.2 will automatically pad CHAR placeholder values to the size of the CHAR. As the default placeholder type value in DBD::Oracle is ORA_VARCHAR2 to access this behaviour you will have to change the default placeholder type with "ora_ph_type" or placeholder type for a particular call with "bind" in DBI or "bind_param_inout" in DBI with "ORA_CHAR". Show quoted text
> So the ORA_VARCHAR2 does not seem to be processed correctly if it
comes Show quoted text
> from DBD::Oracle's exported values (is it being treated as CHAR
instead Show quoted text
> of VARCHAR2?). > > Then I found that I did not get the same issue with the same > code/versions against a different database - and both databases are
the Show quoted text
> same Oracle version too. > Further tests showed that the results were identical even on an old > debian box with an Oracle 10.2 client and an old DBD::Oracle (1.19 I
think). Show quoted text
> > Turns out this was cause by the database's NLS character set (the > "failing" database has AL32UTF8 where the "working" one has
"WE8MSWIN1252"). Show quoted text
> Setting NLS_LANG causes same results as with the non-UTF8 database > (space-padded "Hello World"). > > This still does not (to me) explain why: > - I do get a value when using SQL_VARCHAR or a ORA_VARCHAR2 as a
string Show quoted text
> - I get space-padded results when ORA_VARCHAR2 is used as an import > from DBD::Oracle
Hope this helps. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68173] [1.28] Major problem with ORA_VARCHAR2 inout parameters on Oracle 11
Date: Thu, 19 May 2011 09:04:03 +0200
To: bug-DBD-Oracle [...] rt.cpan.org
From: Tim Van Holder <tim.vanholder [...] anubex.com>
Download (untitled) / with headers
text/plain 4.7k
On 18/05/2011 16:55, Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68173 > > > On Wed May 18 06:53:40 2011, tim.vanholder@anubex.com wrote:
>> I did some follow-up tests. >> >> These work:
> > OK, we are both guilty of not using strict and warnings: > > BTW, your examples don't work for me. I get "Can't bind unknown > placeholder 'myparam'" presumably because that should be ":myparam" in > the bind_param_inout call.
Yeah that's my bad - started out with what's in the mail, but then added in the real connect strings and fixed the placeholder name, but forgot to update the mail to match. Show quoted text
>> perl -le ' >> use DBI; >> my $v; >> my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); >> my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); >> $s->bind_param_inout('myparam', \$v, 4000, { TYPE => ORA_VARCHAR2 }); >> $s-> execute; >> print "result: [$v]\n"; >> '
> > If you add strict you'll see > Bareword "ORA_VARCHAR2" not allowed while "strict subs" in use > I'm not sure right now what TYPE gets set to if you use ORA_VARCHAR2 > without importing it first (probably 0 which probably causes DBD::Oracle > to use the default type).
I only tried it this way because that's what was in your sample :-) I did think it was odd that this was allowed (forgot about strict), but incorrectly assumed that it was stringifying ORA_VARCHAR2 and that DBD::Oracle was checking both the real number and a string. Show quoted text
> The following one should say: > > Argument "ORA_VARCHAR2" isn't numeric > > It needs to be numeric not a string 'ORA_VARCHAR2'. However because you > have not got strict or warnings enabled you do not see that and I guess > the default type is chosen. > > Always use strict and warnings when you get strange results.
My real scripts do - just tend to forget to add it to perl -e samples. Show quoted text
>> (reporting [Hello World]), but these do not: >> perl -le ' >> use DBI; >> use DBD::Oracle qw(:ora_types); >> my $v; >> my $h = DBI->connect("dbi:Oracle:xxx","xxx","xxx"); >> my $s = $h->prepare(q{begin :myparam := 'Hello World'; end;}); >> $s->bind_param_inout('myparam', \$v, 4000, ORA_VARCHAR2); >> $s-> execute; >> print "result: [$v]\n"; >> ' >> (reporting [<lots of spaces>]).
> > The above one is correct systax and uses ORA_VARCHAR2. Like you I get a > large string of what appears to be spaces.
It's the syntax I had. Show quoted text
> You missed out the {ora_type => ORA_VARCHAR2} which I believe is the > correct way to do it. > > Bare in mind some notes in the pod about different string padding > behaviour - search for ORA_VARCHAR2. Here are some excerpts: > > ORA_VARCHAR2 > > Oracle clients using OCI 8 will strip trailing spaces and allow > embedded \0 bytes. Oracle clients using OCI 9.2 do not strip trailing > spaces and allow embedded \0 bytes. This is the normal default > placeholder type.
OK, I guess that explains the space padding (which was not a real issue anyway, since I was stripping them in code). Just what seemed like an odd discrepancy between the two invocations (and am slightly surprised that OCI is actually space-padding VARCHAR2s). Show quoted text
>> So the ORA_VARCHAR2 does not seem to be processed correctly if it
> comes
>> from DBD::Oracle's exported values (is it being treated as CHAR
> instead
>> of VARCHAR2?). >> >> Then I found that I did not get the same issue with the same >> code/versions against a different database - and both databases are
> the
>> same Oracle version too. >> Further tests showed that the results were identical even on an old >> debian box with an Oracle 10.2 client and an old DBD::Oracle (1.19 I
> think).
>> >> Turns out this was cause by the database's NLS character set (the >> "failing" database has AL32UTF8 where the "working" one has
> "WE8MSWIN1252").
>> Setting NLS_LANG causes same results as with the non-UTF8 database >> (space-padded "Hello World"). >> >> This still does not (to me) explain why: >> - I do get a value when using SQL_VARCHAR or a ORA_VARCHAR2 as a
> string
>> - I get space-padded results when ORA_VARCHAR2 is used as an import >> from DBD::Oracle
> > Hope this helps.
It does. I guess the only remaining question is: why does ORA_VARCHAR2 care about NLS_LANG, but SQL_VARCHAR doesn't (both are for variable-length character data so I would rather expect them to do the same basic thing)? Note that I also do _not_ get space padding (or NLS_LANG issues) if I specify no placeholder type at all, which is odd since the man page says that ORA_VARCHAR2 is the default placeholder type. I guess the best thing for me to do is to just use SQL_VARCHAR and SQL_NUMERIC instead of ORA_VARCHAR2 and ORA_NUMBER; aside from getting the preferred behaviour for the strings that should still work if I ever need my code to run against a database other than Oracle.
Download (untitled) / with headers
text/plain 2.4k
<snipped a lot> On Thu May 19 03:08:15 2011, tim.vanholder@anubex.com wrote: Show quoted text
> On 18/05/2011 16:55, Martin J Evans via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=68173 > > > > > On Wed May 18 06:53:40 2011, tim.vanholder@anubex.com wrote:
> >> I did some follow-up tests.
Show quoted text
> > If you add strict you'll see > > Bareword "ORA_VARCHAR2" not allowed while "strict subs" in use > > I'm not sure right now what TYPE gets set to if you use ORA_VARCHAR2 > > without importing it first (probably 0 which probably causes
DBD::Oracle Show quoted text
> > to use the default type).
> > I only tried it this way because that's what was in your sample :-)
Really? I only see TYPE => in my example. Show quoted text
> > You missed out the {ora_type => ORA_VARCHAR2} which I believe is the > > correct way to do it. > > > > Bare in mind some notes in the pod about different string padding > > behaviour - search for ORA_VARCHAR2. Here are some excerpts: > > > > ORA_VARCHAR2 > > > > Oracle clients using OCI 8 will strip trailing spaces and allow > > embedded \0 bytes. Oracle clients using OCI 9.2 do not strip trailing > > spaces and allow embedded \0 bytes. This is the normal default > > placeholder type.
> > OK, I guess that explains the space padding (which was not a real issue > anyway, since I was stripping them in code). Just what seemed like an > odd discrepancy between the two invocations (and am slightly surprised > that OCI is actually space-padding VARCHAR2s).
There is also DBI's ChopBlanks. Show quoted text
> > Hope this helps.
> > It does. I guess the only remaining question is: why does ORA_VARCHAR2 > care about NLS_LANG, but SQL_VARCHAR doesn't (both are for > variable-length character data so I would rather expect them to do the > same basic thing)? > Note that I also do _not_ get space padding (or NLS_LANG issues) if I > specify no placeholder type at all, which is odd since the man page says > that ORA_VARCHAR2 is the default placeholder type. > > I guess the best thing for me to do is to just use SQL_VARCHAR and > SQL_NUMERIC instead of ORA_VARCHAR2 and ORA_NUMBER; aside from getting > the preferred behaviour for the strings that should still work if I ever > need my code to run against a database other than Oracle.
I don't know why you see different behavior. If you want to pursue it I suggest you post to the dbi-users list where there are a lot more Oracle people than read these RTs. What would you consider would close this RT to your satisfaction? Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #68173] [1.28] Major problem with ORA_VARCHAR2 inout parameters on Oracle 11
Date: Thu, 19 May 2011 10:29:42 +0200
To: bug-DBD-Oracle [...] rt.cpan.org
From: Tim Van Holder <tim.vanholder [...] anubex.com>
Download (untitled) / with headers
text/plain 1.9k
On 19/05/2011 10:22, Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68173 > > > <snipped a lot more>
>> >> I only tried it this way because that's what was in your sample :-)
> > Really? I only see TYPE => in my example.
I meant that your sample had TYPE => ORA_VARCHAR2 without the import of :ora_types from DBD::Oracle (only a "use DBI"). Show quoted text
>>> Hope this helps.
>> >> It does. I guess the only remaining question is: why does ORA_VARCHAR2 >> care about NLS_LANG, but SQL_VARCHAR doesn't (both are for >> variable-length character data so I would rather expect them to do the >> same basic thing)? >> Note that I also do _not_ get space padding (or NLS_LANG issues) if I >> specify no placeholder type at all, which is odd since the man page says >> that ORA_VARCHAR2 is the default placeholder type. >> >> I guess the best thing for me to do is to just use SQL_VARCHAR and >> SQL_NUMERIC instead of ORA_VARCHAR2 and ORA_NUMBER; aside from getting >> the preferred behaviour for the strings that should still work if I ever >> need my code to run against a database other than Oracle.
> > I don't know why you see different behavior. If you want to pursue it I > suggest you post to the dbi-users list where there are a lot more Oracle > people than read these RTs. > > What would you consider would close this RT to your satisfaction?
As far as I'm concerned, it can be closed: - the initial case was basically user error (the man page does mention the need for NLS_LANG/NLS_NCHAR for Unicode databases) - I have 2 viable workarounds: - using SQL_VARCHAR instead of ORA_VARCHAR - ensuring that NLS_LANG is set correctly and/or documenting that it should be It just seems like there is some buggyness somewhere: - SQL_VARCHAR doesn't have NLS_LANG issues - even for the NLS_LANG issues: the data being sent is basically US ASCII, so even if character set translation is applied, it should still result in a valid, identical, string (and not blanks without any kind of error)
Download (untitled) / with headers
text/plain 2.4k
On Thu May 19 04:33:53 2011, tim.vanholder@anubex.com wrote: Show quoted text
> On 19/05/2011 10:22, Martin J Evans via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=68173 > > > > > <snipped a lot more>
> >> > >> I only tried it this way because that's what was in your sample :-)
> > > > Really? I only see TYPE => in my example.
> > I meant that your sample had TYPE => ORA_VARCHAR2 without the import of > :ora_types from DBD::Oracle (only a "use DBI").
ok Show quoted text
> >>> Hope this helps.
> >> > >> It does. I guess the only remaining question is: why does ORA_VARCHAR2 > >> care about NLS_LANG, but SQL_VARCHAR doesn't (both are for > >> variable-length character data so I would rather expect them to do the > >> same basic thing)? > >> Note that I also do _not_ get space padding (or NLS_LANG issues) if I > >> specify no placeholder type at all, which is odd since the man page
says Show quoted text
> >> that ORA_VARCHAR2 is the default placeholder type. > >> > >> I guess the best thing for me to do is to just use SQL_VARCHAR and > >> SQL_NUMERIC instead of ORA_VARCHAR2 and ORA_NUMBER; aside from getting > >> the preferred behaviour for the strings that should still work if I
ever Show quoted text
> >> need my code to run against a database other than Oracle.
> > > > I don't know why you see different behavior. If you want to pursue it I > > suggest you post to the dbi-users list where there are a lot more Oracle > > people than read these RTs. > > > > What would you consider would close this RT to your satisfaction?
> > As far as I'm concerned, it can be closed: > - the initial case was basically user error (the man page does mention > the need for NLS_LANG/NLS_NCHAR for Unicode databases) > - I have 2 viable workarounds: > - using SQL_VARCHAR instead of ORA_VARCHAR > - ensuring that NLS_LANG is set correctly and/or documenting that it > should be > > It just seems like there is some buggyness somewhere: > - SQL_VARCHAR doesn't have NLS_LANG issues > - even for the NLS_LANG issues: the data being sent is basically US > ASCII, so even if character set translation is applied, it should > still result in a valid, identical, string (and not blanks without > any kind of error)
I only help maintain DBD::Oracle and don't know all the answers. It would be worth you posting an example to the dbi-users list you can find at http://dbi.perl.org and may be someone else can help identify if there is a real problem. Martin -- Martin J. Evans Wetherby, UK


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.