Re: DBD::Oracle and RHEL8
On Mon, 6 Jul 2020 12:50:44 +0200, Oliver Dörr wrote: > Hi, > > i just tried to install DBD::Oracle 1.80 on RHEL 8 and the make > command failes. > gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib > -fstack-protector-strong Oracle.o dbdimp.o oci8.o -o > blib/arch/auto/DBD/Oracle/Oracle.so \ > -L/db/main/oraclient193/lib -lclntsh -ldl -lm -lpthread -lnsl > -lirc -limf -lirc -lrt -laio -lresolv -lsvml -lperl \ > > */usr/bin/ld: cannot find -lnsl* > collect2: error: ld returned 1 exit status > make: *** [Makefile:524: blib/arch/auto/DBD/Oracle/Oracle.so] Error 1 > > A little research and comparing to RHEL 7 shows the problem. > *RHEL7:* > ll /usr/lib64/libnsl* > -rwxr-xr-x 1 root root 115816 Jan 22 06:19 /usr/lib64/libnsl-2.17.so > *lrwxrwxrwx 1 root root 23 May 5 06:05 /usr/lib64/libnsl.so -> > ../../lib64/libnsl.so.1* > lrwxrwxrwx 1 root root 14 May 5 06:00 /usr/lib64/libnsl.so.1 -> > libnsl-2.17.so > > RHEL8: > ll /usr/lib64/libnsl* > -rwxr-xr-x 1 root root 163520 Jan 16 21:40 /usr/lib64/libnsl-2.28.so > lrwxrwxrwx 1 root root 14 Jan 16 21:29 /usr/lib64/libnsl.so.1 -> > libnsl-2.28.so > lrwxrwxrwx. 1 root root 15 Aug 12 2018 /usr/lib64/libnsl.so.2 -> > libnsl.so.2.0.0 > -rwxr-xr-x. 1 root root 116408 Aug 12 2018 /usr/lib64/libnsl.so.2.0.0 > > > So the softlink is */usr/lib64/libnsl.so* missing in RHEl8. > Everything compiles if I add the softlink, but I'm not sure if this > is a good idea. Should that not be fixed inside the Makefile.PL or so? You most likely forgot to install the libnsl2-devel package $ rpm -qf /usr/lib64/libnsl.so libnsl2-devel-1.2.0-2.20180605git4a062cf.el8.x86_64 $ sudo dnf install -y libnsl2-devel > Any hints are welcome > > Regards > Oliver -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle and RHEL8
On 6/7/20 8:50 pm, Oliver Dörr wrote: Hi, i just tried to install DBD::Oracle 1.80 on RHEL 8 and the make command failes. gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.so \ -L/db/main/oraclient193/lib -lclntsh -ldl -lm -lpthread -lnsl -lirc -limf -lirc -lrt -laio -lresolv -lsvml -lperl \ */usr/bin/ld: cannot find -lnsl* collect2: error: ld returned 1 exit status make: *** [Makefile:524: blib/arch/auto/DBD/Oracle/Oracle.so] Error 1 A little research and comparing to RHEL 7 shows the problem. *RHEL7:* ll /usr/lib64/libnsl* -rwxr-xr-x 1 root root 115816 Jan 22 06:19 /usr/lib64/libnsl-2.17.so *lrwxrwxrwx 1 root root 23 May 5 06:05 /usr/lib64/libnsl.so -> ../../lib64/libnsl.so.1* lrwxrwxrwx 1 root root 14 May 5 06:00 /usr/lib64/libnsl.so.1 -> libnsl-2.17.so RHEL8: ll /usr/lib64/libnsl* -rwxr-xr-x 1 root root 163520 Jan 16 21:40 /usr/lib64/libnsl-2.28.so lrwxrwxrwx 1 root root 14 Jan 16 21:29 /usr/lib64/libnsl.so.1 -> libnsl-2.28.so lrwxrwxrwx. 1 root root 15 Aug 12 2018 /usr/lib64/libnsl.so.2 -> libnsl.so.2.0.0 -rwxr-xr-x. 1 root root 116408 Aug 12 2018 /usr/lib64/libnsl.so.2.0.0 So the softlink is */usr/lib64/libnsl.so* missing in RHEl8. Everything compiles if I add the softlink, but I'm not sure if this is a good idea. Should that not be fixed inside the Makefile.PL or so? Any hints are welcome On RHEL8 or OL8 (or similar) you should install the 'libnsl' package to use Oracle Instant Client. My update to the Instant Client install instructions about this seems to have gone AWOL. A future Instant Client RPM will install this package by default. Work is also ongoing to review the need for this dependency in the first place. Chris -- https://twitter.com/ghrd
Re: DBD::Oracle sometimes return wrong PRECISION
On Wed, 31 Dec 2014 18:49:24 +0100, "H.Merijn Brand"
wrote:
> On Wed, 31 Dec 2014 16:58:02 +0100, "H.Merijn Brand"
> wrote:
>
> > I have something weird in DBD::Oracle (1.44 and 1.74)
> > Client = 10.2.0.1.0 / AIX-5.3 - Server = 11.2.0.3.0 - 64bit / Linux
> >
> > consider a field that looks like this:
> >
> > { LINK => undef,
> > NAME => 'D_GELD',
> > NAME_lc => 'd_geld',
> > NAME_uc => 'D_GELD',
> > NULLABLE => '',
> > PRECISION=> 8,
> > SCALE=> 0,
> > TYPE => 3,
> > TYPE_NAME=> 'DECIMAL',
> > dbd_type => undef,
> > ora_est_row_width => undef,
> > ora_fail_over=> undef,
> > ora_lengths => 172,
> > ora_rowid=> undef,
> > ora_type => undef,
> > ora_types=> 2
> > }
> >
> > *sometimes* I get 126 in the PRECISION entry instead of 8
> > does that ring any bells?
> >
> > I get 126 only if I use a where clause that addresses a field that is
> > first in an index on that table otherwise I get 8
>
> I can reproduce it with this:
>
> --8<--- test.pl
> use 5.16.2;
> use warnings;
>
> use DBI;
>
> my $dbh = DBI->connect ("dbi:Oracle:", $ENV{DBI_USER}, $ENV{DBI_PASS}, {
> RaiseError => 1,
> PrintError => 1,
> AutoCommit => 1,
> ChopBlanks => 1,
> ShowErrorStatement => 1,
> FetchHashKeyName => "NAME_lc",
> });
>
> say "DBI: $DBI::VERSION";
> say "DBD: $DBD::Oracle::VERSION";
> say "OCI: ", ORA_OCI;
> say "Svr: @{$dbh->func ('ora_server_version')}";
>
> $dbh->do (qq;
> create table foo (
> a1 number (3) default -1,
> a2 number (4) default -1,
> a3 number (3) default -1,
> d_foonumber (8) default -1,
> v_foonumber (2) default 0,
> hist char (1) default 'A'
> ););
>
> sub prec
> {
> my $sth = $dbh->prepare (shift);
> $sth->execute;
> printf "PRECISION: %3d, St: %s\n", $sth->{PRECISION}[3],
> $sth->{Statement};
> } # prec
>
> sub test
> {
> prec ("select a1, a2, a3, d_foo, v_foo from foo");
> prec ("select a1, a2, a3, d_foo, v_foo from foo where a1 = 111");
> prec ("select a1, a2, a3, d_foo, v_foo from foo where a2 = 111");
> prec ("select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111");
> } # test
>
> test ();
>
> $dbh->do ("insert into foo values (101, 101, 25, 19841213, 0, 'A')");
>
> test ();
>
> $dbh->do ("create index idx_foo on foo (a1, a2, a3, d_foo desc, v_foo desc,
> hist)");
>
> test ();
>
> END { $dbh->do ("drop table foo"); }
> -->8---
>
> $ perl test.pl
> DBI: 1.632
> DBD: 1.74
> OCI: 11.2.0.3
> Svr: 11 2 0 3 0
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
> PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
> PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
> PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
>
>
> SQL*Plus: Release 11.2.0.3.0 Production on Wed Dec 31 18:42:36 2014
> This is perl 5, version 20, subversion 0 (v5.20.0) built for
> x86_64-linux-thread-multi-ld
SQLite (all undef):
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
MySQL:
PRECISION: 9, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 9, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 9, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 9, St: select a1, a2, a3, d_foo, v_foo from
Re: DBD::Oracle sometimes return wrong PRECISION
On Wed, 31 Dec 2014 16:58:02 +0100, "H.Merijn Brand"
wrote:
> I have something weird in DBD::Oracle (1.44 and 1.74)
> Client = 10.2.0.1.0 / AIX-5.3 - Server = 11.2.0.3.0 - 64bit / Linux
>
> consider a field that looks like this:
>
> { LINK => undef,
> NAME => 'D_GELD',
> NAME_lc => 'd_geld',
> NAME_uc => 'D_GELD',
> NULLABLE => '',
> PRECISION=> 8,
> SCALE=> 0,
> TYPE => 3,
> TYPE_NAME=> 'DECIMAL',
> dbd_type => undef,
> ora_est_row_width => undef,
> ora_fail_over=> undef,
> ora_lengths => 172,
> ora_rowid=> undef,
> ora_type => undef,
> ora_types=> 2
> }
>
> *sometimes* I get 126 in the PRECISION entry instead of 8
> does that ring any bells?
>
> I get 126 only if I use a where clause that addresses a field that is
> first in an index on that table otherwise I get 8
I can reproduce it with this:
--8<--- test.pl
use 5.16.2;
use warnings;
use DBI;
my $dbh = DBI->connect ("dbi:Oracle:", $ENV{DBI_USER}, $ENV{DBI_PASS}, {
RaiseError => 1,
PrintError => 1,
AutoCommit => 1,
ChopBlanks => 1,
ShowErrorStatement => 1,
FetchHashKeyName => "NAME_lc",
});
say "DBI: $DBI::VERSION";
say "DBD: $DBD::Oracle::VERSION";
say "OCI: ", ORA_OCI;
say "Svr: @{$dbh->func ('ora_server_version')}";
$dbh->do (qq;
create table foo (
a1 number (3) default -1,
a2 number (4) default -1,
a3 number (3) default -1,
d_foonumber (8) default -1,
v_foonumber (2) default 0,
hist char (1) default 'A'
););
sub prec
{
my $sth = $dbh->prepare (shift);
$sth->execute;
printf "PRECISION: %3d, St: %s\n", $sth->{PRECISION}[3], $sth->{Statement};
} # prec
sub test
{
prec ("select a1, a2, a3, d_foo, v_foo from foo");
prec ("select a1, a2, a3, d_foo, v_foo from foo where a1 = 111");
prec ("select a1, a2, a3, d_foo, v_foo from foo where a2 = 111");
prec ("select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111");
} # test
test ();
$dbh->do ("insert into foo values (101, 101, 25, 19841213, 0, 'A')");
test ();
$dbh->do ("create index idx_foo on foo (a1, a2, a3, d_foo desc, v_foo desc,
hist)");
test ();
END { $dbh->do ("drop table foo"); }
-->8---
$ perl test.pl
DBI: 1.632
DBD: 1.74
OCI: 11.2.0.3
Svr: 11 2 0 3 0
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
SQL*Plus: Release 11.2.0.3.0 Production on Wed Dec 31 18:42:36 2014
This is perl 5, version 20, subversion 0 (v5.20.0) built for
x86_64-linux-thread-multi-ld
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.21 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/
pgp6dS65H8sK6.pgp
Description: OpenPGP digital signature
Re: DBD::Oracle 1.72 fail
On Thu, 22 May 2014 07:49:15 -0700, Christopher Jones wrote: > On 5/21/14, 11:03 PM, H.Merijn Brand wrote: > > On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones > > wrote: > > > >> > >> > >> On 05/19/2014 01:48 PM, H.Merijn Brand wrote: > >>> On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones > >>> wrote: > >>> > > I appreciate the wealth of information. > It really does help when we have to prioritize project and features. > >>> > >>> FEEDBACK! > >>> > >>> I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) > >> > >> It sounds like you have a client using 12c libraries from a mixed > >> environment directory! > >> I'd have to ask "why?". I couldn't recommend doing it. > > > > Neither would I, BUT … > > > > perl-5.14.2 and newer with OpenSSL-1.0.0 or newer and DBD::Oracle does > > not work for quite a few of our applications when linking DBD::Oracle > > to the 10g client that is available in the 10g database environment. > > The problem is the interesting part. I'd like to know what "does not > work". Our SOAP clients. I am not able/allowed to reveal code on that. I might be able to reproduce an error message, but as I recall the message, it did not hint to *anything* useful at all > > The client is not (yet) willing to move on to 11g or 12c, so the 10g is > > there to stay. > > It sounds like you've moved them, at least for Perl. No, they are fully 10g, but now the 10g /lib has three extra .so's from 12c and those timezone files: their 10g installation doesn't care if there are a few extra files in there. They are just used by DBD::Oracle > Chris -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 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/
Re: DBD::Oracle 1.72 fail
On 5/21/14, 11:03 PM, H.Merijn Brand wrote: On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones wrote: On 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones wrote: I appreciate the wealth of information. It really does help when we have to prioritize project and features. FEEDBACK! I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) It sounds like you have a client using 12c libraries from a mixed environment directory! I'd have to ask "why?". I couldn't recommend doing it. Neither would I, BUT … perl-5.14.2 and newer with OpenSSL-1.0.0 or newer and DBD::Oracle does not work for quite a few of our applications when linking DBD::Oracle to the 10g client that is available in the 10g database environment. The problem is the interesting part. I'd like to know what "does not work". The client is not (yet) willing to move on to 11g or 12c, so the 10g is there to stay. It sounds like you've moved them, at least for Perl. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones wrote: > > > On 05/19/2014 01:48 PM, H.Merijn Brand wrote: > > On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones > > wrote: > > > >> > >> I appreciate the wealth of information. > >> It really does help when we have to prioritize project and features. > > > > FEEDBACK! > > > > I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) > > It sounds like you have a client using 12c libraries from a mixed environment > directory! > I'd have to ask "why?". I couldn't recommend doing it. Neither would I, BUT … perl-5.14.2 and newer with OpenSSL-1.0.0 or newer and DBD::Oracle does not work for quite a few of our applications when linking DBD::Oracle to the 10g client that is available in the 10g database environment. The client is not (yet) willing to move on to 11g or 12c, so the 10g is there to stay. Being a perl-hacker one tries to find a way to make it work :) The whole thing worked fine (same OS, same perl, same version of DBI and DBD::Oracle and the same version of OpenSSL) under a 12c install environment, so the obvious solution is to try to get DBD::Oracle linked against 12c client libraries working in the 10g environment to make the client, and thus us, happy. > Chris > > > 1. Install 12c-client for HP-UX itanium > > 2. Build DBD::Oracle against that and install > > > > 3. Move to the 10g environment > > 4. Get these files from 12c into the 10g tree: none of them overwrites > > an other file! > > > > lib/libclntsh.so.12.1 > > lib/libnnz12.so > > lib/libclntshcore.so.12.1 > > oracore/zoneinfo/timezdif.csv > > oracore/zoneinfo/timezlrg_1.dat > > oracore/zoneinfo/timezlrg_10.dat > > oracore/zoneinfo/timezlrg_11.dat > > oracore/zoneinfo/timezlrg_12.dat > > oracore/zoneinfo/timezlrg_13.dat > > oracore/zoneinfo/timezlrg_14.dat > > oracore/zoneinfo/timezlrg_15.dat > > oracore/zoneinfo/timezlrg_16.dat > > oracore/zoneinfo/timezlrg_17.dat > > oracore/zoneinfo/timezlrg_18.dat > > oracore/zoneinfo/timezlrg_2.dat > > oracore/zoneinfo/timezlrg_3.dat > > oracore/zoneinfo/timezlrg_4.dat > > oracore/zoneinfo/timezlrg_5.dat > > oracore/zoneinfo/timezlrg_6.dat > > oracore/zoneinfo/timezlrg_7.dat > > oracore/zoneinfo/timezlrg_8.dat > > oracore/zoneinfo/timezlrg_9.dat > > oracore/zoneinfo/timezone_1.dat > > oracore/zoneinfo/timezone_10.dat > > oracore/zoneinfo/timezone_11.dat > > oracore/zoneinfo/timezone_12.dat > > oracore/zoneinfo/timezone_13.dat > > oracore/zoneinfo/timezone_14.dat > > oracore/zoneinfo/timezone_15.dat > > oracore/zoneinfo/timezone_16.dat > > oracore/zoneinfo/timezone_17.dat > > oracore/zoneinfo/timezone_18.dat > > oracore/zoneinfo/timezone_2.dat > > oracore/zoneinfo/timezone_3.dat > > oracore/zoneinfo/timezone_4.dat > > oracore/zoneinfo/timezone_5.dat > > oracore/zoneinfo/timezone_6.dat > > oracore/zoneinfo/timezone_7.dat > > oracore/zoneinfo/timezone_8.dat > > oracore/zoneinfo/timezone_9.dat > > > > > > HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 4075 Mb > > > > This is perl 5, version 14, subversion 2 (v5.14.2) built for > > IA64.ARCHREV_0-LP64-ld > > > > DBI-1.631 > > DBD::Oracle-1.74 > > > > SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 19 22:45:19 2014 > > > > Copyright (c) 1982, 2005, Oracle. All rights reserved. > > > > > > Connected to: > > Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production > > With the Partitioning, OLAP and Data Mining options > > > > $ llldd > > /pro/asql/o83R/lib/perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBD/Oracle/Oracle.so > > > > Lib Real path > > Size DateRefs > > > > - --- > > /pro/asql/o83R/lib/perl/5.14.2/IA64. /pro/asql/o83R/lib/perl/5.14.2/IA64. > > 668072 2014-05-19 18:39:46 25 > > /pro/oracle/v102/lib/libclntsh.so.12 /pro/oracle/v102/lib/libclntsh.so.12 > > 117402552 2014-05-19 18:33:03 21 > > /pro/oracle/v102/lib/libnnz12.so /pro/oracle/v102/lib/libnnz12.so > > 16442824 2013-12-05 09:29:34 12 > > /pro/oracle/v102/lib/libclntshcore.s /pro/oracle/v102/lib/libclntshcore.s > > 14541616 2014-05-19 18:33:03 11 > > /usr/lib/hpux64/librt.so.1 /usr/lib/hpux64/librt.so.1 > > 85568 2007-02-15 22:36:361 > > /usr/lib/hpux64/libdl.so.1 /usr/lib/hpux64/libdl.so.1 > > 78704 2012-07-20 08:34:040 > > /usr/lib/hpux64/libm.so.1/usr/lib/hpux64/libm.so.1 > > 6481912 2011-05-18 22:53:120 > > /usr/lib/hpux64/libpthread.so.1 /usr/lib/hpux64/libpthread.so.1 > > 1613024 2011-08-10 22:04:540 > > /usr/lib/hpux64/libnsl.so.1 /usr/lib/hpux64/libnsl.so.1 > > 1511400 2010-07-30 16:06:083 > > /usr/lib/hpux64/libc.so.1/usr/lib/hpux64/libc.so.1 > > 4900360 2012-08-27 09:33:451 > > /usr/lib/hpux64/li
Re: DBD::Oracle 1.72 fail
On 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones wrote: I appreciate the wealth of information. It really does help when we have to prioritize project and features. FEEDBACK! I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) It sounds like you have a client using 12c libraries from a mixed environment directory! I'd have to ask "why?". I couldn't recommend doing it. Chris 1. Install 12c-client for HP-UX itanium 2. Build DBD::Oracle against that and install 3. Move to the 10g environment 4. Get these files from 12c into the 10g tree: none of them overwrites an other file! lib/libclntsh.so.12.1 lib/libnnz12.so lib/libclntshcore.so.12.1 oracore/zoneinfo/timezdif.csv oracore/zoneinfo/timezlrg_1.dat oracore/zoneinfo/timezlrg_10.dat oracore/zoneinfo/timezlrg_11.dat oracore/zoneinfo/timezlrg_12.dat oracore/zoneinfo/timezlrg_13.dat oracore/zoneinfo/timezlrg_14.dat oracore/zoneinfo/timezlrg_15.dat oracore/zoneinfo/timezlrg_16.dat oracore/zoneinfo/timezlrg_17.dat oracore/zoneinfo/timezlrg_18.dat oracore/zoneinfo/timezlrg_2.dat oracore/zoneinfo/timezlrg_3.dat oracore/zoneinfo/timezlrg_4.dat oracore/zoneinfo/timezlrg_5.dat oracore/zoneinfo/timezlrg_6.dat oracore/zoneinfo/timezlrg_7.dat oracore/zoneinfo/timezlrg_8.dat oracore/zoneinfo/timezlrg_9.dat oracore/zoneinfo/timezone_1.dat oracore/zoneinfo/timezone_10.dat oracore/zoneinfo/timezone_11.dat oracore/zoneinfo/timezone_12.dat oracore/zoneinfo/timezone_13.dat oracore/zoneinfo/timezone_14.dat oracore/zoneinfo/timezone_15.dat oracore/zoneinfo/timezone_16.dat oracore/zoneinfo/timezone_17.dat oracore/zoneinfo/timezone_18.dat oracore/zoneinfo/timezone_2.dat oracore/zoneinfo/timezone_3.dat oracore/zoneinfo/timezone_4.dat oracore/zoneinfo/timezone_5.dat oracore/zoneinfo/timezone_6.dat oracore/zoneinfo/timezone_7.dat oracore/zoneinfo/timezone_8.dat oracore/zoneinfo/timezone_9.dat HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 4075 Mb This is perl 5, version 14, subversion 2 (v5.14.2) built for IA64.ARCHREV_0-LP64-ld DBI-1.631 DBD::Oracle-1.74 SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 19 22:45:19 2014 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options $ llldd /pro/asql/o83R/lib/perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBD/Oracle/Oracle.so Lib Real pathSize DateRefs - --- /pro/asql/o83R/lib/perl/5.14.2/IA64. /pro/asql/o83R/lib/perl/5.14.2/IA64. 668072 2014-05-19 18:39:46 25 /pro/oracle/v102/lib/libclntsh.so.12 /pro/oracle/v102/lib/libclntsh.so.12 117402552 2014-05-19 18:33:03 21 /pro/oracle/v102/lib/libnnz12.so /pro/oracle/v102/lib/libnnz12.so 16442824 2013-12-05 09:29:34 12 /pro/oracle/v102/lib/libclntshcore.s /pro/oracle/v102/lib/libclntshcore.s 14541616 2014-05-19 18:33:03 11 /usr/lib/hpux64/librt.so.1 /usr/lib/hpux64/librt.so.1 85568 2007-02-15 22:36:361 /usr/lib/hpux64/libdl.so.1 /usr/lib/hpux64/libdl.so.1 78704 2012-07-20 08:34:040 /usr/lib/hpux64/libm.so.1/usr/lib/hpux64/libm.so.1 6481912 2011-05-18 22:53:120 /usr/lib/hpux64/libpthread.so.1 /usr/lib/hpux64/libpthread.so.1 1613024 2011-08-10 22:04:540 /usr/lib/hpux64/libnsl.so.1 /usr/lib/hpux64/libnsl.so.1 1511400 2010-07-30 16:06:083 /usr/lib/hpux64/libc.so.1/usr/lib/hpux64/libc.so.1 4900360 2012-08-27 09:33:451 /usr/lib/hpux64/libxti.so.1 /usr/lib/hpux64/libxti.so.1 298552 2011-02-22 16:00:360 /usr/lib/hpux64/libunwind.so.1 /usr/lib/hpux64/libunwind.so.1 714608 2010-12-06 22:57:421 /usr/lib/hpux64/libuca.so.1 /usr/lib/hpux64/libuca.so.1 85680 2007-02-15 22:36:360 /usr/lib/hpux64/libdiskown.so/usr/lib/hpux64/libdiskown.so.1 95736 2013-04-01 10:43:490 /pro/oracle/v102/lib/libons.so /pro/oracle/v102/lib/libons10.so 218944 2005-06-27 10:04:005 In the end, all products work with both the libons.so from 10g as well as with libons.so from 12c -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones wrote: > > I appreciate the wealth of information. > It really does help when we have to prioritize project and features. FEEDBACK! I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) 1. Install 12c-client for HP-UX itanium 2. Build DBD::Oracle against that and install 3. Move to the 10g environment 4. Get these files from 12c into the 10g tree: none of them overwrites an other file! lib/libclntsh.so.12.1 lib/libnnz12.so lib/libclntshcore.so.12.1 oracore/zoneinfo/timezdif.csv oracore/zoneinfo/timezlrg_1.dat oracore/zoneinfo/timezlrg_10.dat oracore/zoneinfo/timezlrg_11.dat oracore/zoneinfo/timezlrg_12.dat oracore/zoneinfo/timezlrg_13.dat oracore/zoneinfo/timezlrg_14.dat oracore/zoneinfo/timezlrg_15.dat oracore/zoneinfo/timezlrg_16.dat oracore/zoneinfo/timezlrg_17.dat oracore/zoneinfo/timezlrg_18.dat oracore/zoneinfo/timezlrg_2.dat oracore/zoneinfo/timezlrg_3.dat oracore/zoneinfo/timezlrg_4.dat oracore/zoneinfo/timezlrg_5.dat oracore/zoneinfo/timezlrg_6.dat oracore/zoneinfo/timezlrg_7.dat oracore/zoneinfo/timezlrg_8.dat oracore/zoneinfo/timezlrg_9.dat oracore/zoneinfo/timezone_1.dat oracore/zoneinfo/timezone_10.dat oracore/zoneinfo/timezone_11.dat oracore/zoneinfo/timezone_12.dat oracore/zoneinfo/timezone_13.dat oracore/zoneinfo/timezone_14.dat oracore/zoneinfo/timezone_15.dat oracore/zoneinfo/timezone_16.dat oracore/zoneinfo/timezone_17.dat oracore/zoneinfo/timezone_18.dat oracore/zoneinfo/timezone_2.dat oracore/zoneinfo/timezone_3.dat oracore/zoneinfo/timezone_4.dat oracore/zoneinfo/timezone_5.dat oracore/zoneinfo/timezone_6.dat oracore/zoneinfo/timezone_7.dat oracore/zoneinfo/timezone_8.dat oracore/zoneinfo/timezone_9.dat HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 4075 Mb This is perl 5, version 14, subversion 2 (v5.14.2) built for IA64.ARCHREV_0-LP64-ld DBI-1.631 DBD::Oracle-1.74 SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 19 22:45:19 2014 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options $ llldd /pro/asql/o83R/lib/perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBD/Oracle/Oracle.so Lib Real pathSize DateRefs - --- /pro/asql/o83R/lib/perl/5.14.2/IA64. /pro/asql/o83R/lib/perl/5.14.2/IA64. 668072 2014-05-19 18:39:46 25 /pro/oracle/v102/lib/libclntsh.so.12 /pro/oracle/v102/lib/libclntsh.so.12 117402552 2014-05-19 18:33:03 21 /pro/oracle/v102/lib/libnnz12.so /pro/oracle/v102/lib/libnnz12.so 16442824 2013-12-05 09:29:34 12 /pro/oracle/v102/lib/libclntshcore.s /pro/oracle/v102/lib/libclntshcore.s 14541616 2014-05-19 18:33:03 11 /usr/lib/hpux64/librt.so.1 /usr/lib/hpux64/librt.so.1 85568 2007-02-15 22:36:361 /usr/lib/hpux64/libdl.so.1 /usr/lib/hpux64/libdl.so.1 78704 2012-07-20 08:34:040 /usr/lib/hpux64/libm.so.1/usr/lib/hpux64/libm.so.1 6481912 2011-05-18 22:53:120 /usr/lib/hpux64/libpthread.so.1 /usr/lib/hpux64/libpthread.so.1 1613024 2011-08-10 22:04:540 /usr/lib/hpux64/libnsl.so.1 /usr/lib/hpux64/libnsl.so.1 1511400 2010-07-30 16:06:083 /usr/lib/hpux64/libc.so.1/usr/lib/hpux64/libc.so.1 4900360 2012-08-27 09:33:451 /usr/lib/hpux64/libxti.so.1 /usr/lib/hpux64/libxti.so.1 298552 2011-02-22 16:00:360 /usr/lib/hpux64/libunwind.so.1 /usr/lib/hpux64/libunwind.so.1 714608 2010-12-06 22:57:421 /usr/lib/hpux64/libuca.so.1 /usr/lib/hpux64/libuca.so.1 85680 2007-02-15 22:36:360 /usr/lib/hpux64/libdiskown.so/usr/lib/hpux64/libdiskown.so.1 95736 2013-04-01 10:43:490 /pro/oracle/v102/lib/libons.so /pro/oracle/v102/lib/libons10.so 218944 2005-06-27 10:04:005 In the end, all products work with both the libons.so from 10g as well as with libons.so from 12c > Chris > > On 4/17/14, 11:41 PM, H.Merijn Brand wrote: > > On Thu, 17 Apr 2014 15:55:27 -0700, Christopher Jones > > wrote: > > > >> > >> [I thought I'd replied this morning, but can't see it in my outbox] > >> > >> On 04/16/2014 08:42 AM, H.Merijn Brand wrote: > >>> On Wed, 16 Apr 2014 08:18:10 -0700, Christopher Jones > >>> wrote: > >>> > Hi, > > An enhancement request for including tnsping already exists in the > Oracle bug database. If you can give me a description of how you use > tnsping, I will add it to the enhancement request. Having the actual > words of a customer always helps prioritization and design. > >>> > >>>$ tnsping $TWO_TASK > >> > >> To be sure I understand: > >> - Do you run
Re: DBD::Oracle 1.72 fail
On 15/04/2014 12:38, H.Merijn Brand wrote:
Builds fail on Linux with OIC-12.1
As a side note, is anyone able to fetch Oracle Instant Client-12 for
HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :(
http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html
# Box 1
Linux 3.11.10-7-desktop [openSUSE 13.1 (Bottle)] x86_64 Xeon(R) CPU E5-1650 0
@ 3.20GHz/3072(12) x86_64 16008 Mb
Using DBI 1.631 (for perl 5.016002 on x86_64-linux-ld) installed in
/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI/
Configuring DBD::Oracle for perl 5.016002 on linux (x86_64-linux-ld)
Installing on a linux, Ver#3.4
Using Oracle in /usr/lib/oracle/12.1/client64
DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR)
Oracle version 12.1.0.1 (12.1)
Found /usr/share/oracle/12.1/client64/demo.mk
Using /usr/share/oracle/12.1/client64/demo.mk
ccache cc -c -I/usr/include/oracle/12.1/client64 -I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" -fPIC
"-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64 -I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" -fPIC
"-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: In function âora_st_FETCH_attribâ:
dbdimp.c:4355:31: error: âimp_dbhâ undeclared (first use in this function)
if (CSFORM_IMPLIES_UTF8(SQLCS_IMPLICIT)) {
^
dbdimp.c:4355:31: note: each undeclared identifier is reported only once for
each function it appears in
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
# Box 2
Linux 3.11.10-7-desktop [openSUSE 13.1 (Bottle)] i386 Core(TM) i7-2620M CPU @
2.70GHz/2619(4) i686 8032 Mb
Using DBI 1.631 (for perl 5.018002 on i686-linux-64int-ld) installed in
/pro/lib/perl5/site_perl/5.18.2/i686-linux-64int-ld/auto/DBI/
Configuring DBD::Oracle for perl 5.018002 on linux (i686-linux-64int-ld)
Using Oracle in /usr/lib/oracle/12.1/client
DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR)
Oracle version 12.1.0.1 (12.1)
Found /usr/share/oracle/12.1/client/demo.mk
Using /usr/share/oracle/12.1/client/demo.mk
cc -c -I/usr/include/oracle/12.1/client -I/pro/lib/perl5/site_perl/5.18.2/i686-linux-64int-ld/auto/DBI
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" -fPIC
"-I/pro/lib/perl5/5.18.2/i686-linux-64int-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c
dbdimp.c: In function âdbd_rebind_ph_charâ:
dbdimp.c:2558:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âIVâ [-Wformat=]
"Growing 96 phs sv to %ld resulted in buffer
%ld\n", phs->maxlen - 1, SvLEN(phs->sv)
^
dbdimp.c:2558:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 4 has type âSTRLENâ [-Wformat=]
dbdimp.c:2572:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âIVâ [-Wformat=]
"Growing phs sv to %ld resulted in buffer %ld\n",
phs->maxlen +1, SvLEN(phs->sv));
^
dbdimp.c:2572:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 4 has type âSTRLENâ [-Wformat=]
dbdimp.c:2605:27: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âSTRLENâ [-Wformat=]
"Changing maxlen to %ld\n", SvLEN(phs->sv));
^
dbdimp.c: In function âdbd_rebind_ph_xmlâ:
dbdimp.c:2889:17: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
phs->progv = (void*) SvIV(ptr);
^
In file included from Oracle.h:52:0,
from dbdimp.c:21:
dbdimp.c: In function âora_st_FETCH_attribâ:
dbdimp.h:311:27: error: âimp_dbhâ undeclared (first use in this function)
((csform==SQLCS_NCHAR) ? imp_dbh->ncharsetid : imp_dbh->charsetid)
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 13:38:38 +0200, "H.Merijn Brand" wrote: > Builds fail on Linux with OIC-12.1 tl;dr; if you are not interested in porting DBD::Oracle I have now installed/gathered the available stuff for HP-UX Itanium 64bit, moved all into the required locations and tried to build DBD::Oracle Using rpm's on Linux is straightforward, and all works immediately after that. On HP-UX, one has to move the files a bit after extracting the following zips: instantclient-basic-hpux.ia64-12.1.0.1.0.zip instantclient-jdbc-hpux.ia64-12.1.0.1.0.zip instantclient-odbc-hpux.ia64-12.1.0.1.0.zip instantclient-sdk-hpux.ia64-12.1.0.1.0.zip instantclient-sqlplus-hpux.ia64-12.1.0.1.0.zip instantclient-tools-hpux.ia64-12.1.0.1.0.zip instantclient-precomp-hpux.ia64-12.1.0.1.0.zip I added tnsping from the 10.2 database product (and the two required messgae files). The Instant Client seems to work: DBD-Oracle-1.72-2g6rU8 511 > tnsping $TWO_TASK TNS Ping Utility for HPUX: Version 10.2.0.1.0 - Production on 16-APR-2014 10:38:17 Copyright (c) 1997, 2005, Oracle. All rights reserved. Used parameter files: /pro/oracle/ic121/network/admin/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact ( DESCRIPTION = ( ADDRESS_LIST = ( ADDRESS = ( HOST = dbo)( PORT = 1521)( PROTOCOL = TCP))) ( CONNECT_DATA = ( SERVICE_NAME = xxx0123))) OK (210 msec) DBD-Oracle-1.72-2g6rU8 512 > sqlplus $ORACLE_USERID SQL*Plus: Release 12.1.0.1.0 Production on Wed Apr 16 10:40:49 2014 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> So far so good. I had to read Makefile.PL to check what it expects where, as all those zips install in different locations. The final SUCCESS for that stage results in DBD-Oracle-1.72-2g6rU8 520 > perl Makefile.PL Using DBI 1.631 (for perl 5.014002 on IA64.ARCHREV_0-LP64-ld) installed in /pro/lib/perl5/site_perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBI/ Configuring DBD::Oracle for perl 5.014002 on hpux (IA64.ARCHREV_0-LP64-ld) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a hpux, Ver#11.31 Using Oracle in /pro/oracle/ic121 DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR) Oracle version 12.1.0.1 (12.1) Looks like an Instant Client installation, okay Your LD_LIBRARY_PATH/SHLIB_PATH env var is set to '/pro/oracle/ic121/lib:/pro/local/lib:/usr/local/ssl/lib:/pro/pgsql/lib:/usr/local/lib:/usr/lib/hpux64:/usr/lib:/pro/pgsql/lib:/etc/opt/resmon/lib:/opt/gnome/lib:/usr/local/ia64/lib/hpux64' WARNING: Your LD_LIBRARY_PATH/SHLIB_PATH env var doesn't include '/pro/oracle/ic121' but probably needs to. Oracle sysliblist: Found header files in /pro/oracle/ic121/sdk/include. client_version=12.1 DEFINE= -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 WARNING: If you have trouble, see README.hpux.txt... you may have to build your own perl, or go hunting for libraries WARNING: If you have trouble, try perl Makefile.PL -l Checking for functioning wait.ph System: perl5.014002 hp-ux x2 b.11.31 u ia64 2977233888 unlimited-user license Compiler: cc +O2 +Onolimit -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Linker: /usr/bin/ld Sysliblist: Linking with -lclntsh. WARNING: If you have problems you may need to rebuild perl with threading enabled. LD_RUN_PATH=/pro/oracle/ic121 Using DBD::Oracle 1.72. Using DBD::Oracle 1.72. Using DBI 1.631 (for perl 5.014002 on IA64.ARCHREV_0-LP64-ld) installed in /pro/lib/perl5/site_perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBI/ Generating a Unix-style Makefile Writing Makefile for DBD::Oracle Writing MYMETA.yml and MYMETA.json *** If you have problems... read all the log printed above, and the README and README.help.txt files. (Of course, you have read README by now anyway, haven't you?) Next, building … cc -c -I/pro/oracle/ic121/sdk/include -I/pro/lib/perl5/site_perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBI -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit -DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" +Z "-I/pro/lib/perl5/5.14.2/IA64.ARCHREV_0-LP64-ld/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c "/pro/lib/perl5/5.14.2/IA64.ARCHREV_0-LP64-ld/CORE/regexp.h", line 329: warning #2111-D: statement is unreachable return "?"; /* Unknown */ ^ "dbdimp.c", line 736: warning #2181-D: argument is incompatible with corresponding format string conversion strlen(uid), ^ "dbdimp.c", line 738: warning #2181-D: argument is incompatible with corresponding fo
Re: DBD::Oracle 1.72 fail
On 4/15/14, 10:56 AM, H.Merijn Brand wrote: On Tue, 15 Apr 2014 10:33:19 -0700, Christopher Jones wrote: On 04/15/2014 04:38 AM, H.Merijn Brand wrote: As a side note, is anyone able to fetch Oracle Instant Client-12 for HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :( http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html It downloads for me: I had to log into OTN first, though. If you can describe your actual problem, I can ask an admin to review it. My colleague is currently downloading all of them. Lets just assume it was a temporary glitch FWIW I also logged in to OTN before I tried Thanks for the status update. Let me know if the issue reappears. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 10:33:19 -0700, Christopher Jones wrote: > On 04/15/2014 04:38 AM, H.Merijn Brand wrote: > > > As a side note, is anyone able to fetch Oracle Instant Client-12 for > > HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :( > > http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html > > It downloads for me: I had to log into OTN first, though. > If you can describe your actual problem, I can ask an admin to review it. My colleague is currently downloading all of them. Lets just assume it was a temporary glitch FWIW I also logged in to OTN before I tried -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 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/
Re: DBD::Oracle 1.72 fail
On 04/15/2014 04:38 AM, H.Merijn Brand wrote: As a side note, is anyone able to fetch Oracle Instant Client-12 for HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :( http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html It downloads for me: I had to log into OTN first, though. If you can describe your actual problem, I can ask an admin to review it. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On 2014-04-15, 11:18 AM, H.Merijn Brand wrote: Is 1.70 faring any better? Thanks, that help a lot! The culprit seems to be https://github.com/pythian/DBD-Oracle/commit/957f54750ba8c1972beabd1dcd305bd6c47c4586 I'll check with Martin, as he wrote the code and has much, much higher chances to understand what is going there. :-) Cheers, `/anick -- Yanick Champoux Solutions Architect Pythian - Love your data champ...@pythian.com Tel: +1 613 565 8696 x 274 www.pythian.com -- --
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 11:06:47 -0400, Yanick Champoux
wrote:
> On 2014-04-15, 7:38 AM, H.Merijn Brand wrote:
> > Builds fail on Linux with OIC-12.1
>
> Is 1.70 faring any better? If I read the logs correctly, the problem is
>
> > dbdimp.h:311:27: error: âimp_dbhâ undeclared (first use in this function)
> >((csform==SQLCS_NCHAR) ? imp_dbh->ncharsetid : imp_dbh->charsetid)
>
> and that didn't change since last December, so it should be in 1.70, but
> not 1.68.
$ git co v1.70
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.70\"
-DXS_VERSION=\"1.70\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.70\"
-DXS_VERSION=\"1.70\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:725:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:725:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
^
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.70\"
-DXS_VERSION=\"1.70\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 oci8.c
oci8.c: In function âora_blob_read_mb_pieceâ:
oci8.c:1847:4: warning: format â%luâ expects argument of type âlong unsigned
intâ, but argument 6 has type âub4â [-Wformat=]
fbh->field_num+1, ftype, offset, len, destoffset, ul_t(amtp));
^
oci8.c: At top level:
oci8.c:20:93: warning: âdbi_get_stateâ defined but not used [-Wunused-function]
DBISTATE_DECLARE;
^
$ git co v1.71_00
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.71_00\"
-DXS_VERSION=\"1.71_00\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.71_00\"
-DXS_VERSION=\"1.71_00\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: In function âora_st_FETCH_attribâ:
dbdimp.c:4355:31: error: âimp_dbhâ undeclared (first use in this function)
if (CSFORM_IMPLIES_UTF8(SQLCS_IMPLICIT)) {
^
dbdimp.c:4355:31: note: each undeclared identifier is reported only once for
each function it appears in
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
^
make: *** [dbdimp.o] Error 1
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.19 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/
Re: DBD::Oracle 1.72 fail
On 2014-04-15, 7:38 AM, H.Merijn Brand wrote: Builds fail on Linux with OIC-12.1 Is 1.70 faring any better? If I read the logs correctly, the problem is dbdimp.h:311:27: error: âimp_dbhâ undeclared (first use in this function) ((csform==SQLCS_NCHAR) ? imp_dbh->ncharsetid : imp_dbh->charsetid) and that didn't change since last December, so it should be in 1.70, but not 1.68. Cheers, `/anick -- Yanick Champoux Solutions Architect Pythian - Love your data champ...@pythian.com Tel: +1 613 565 8696 x 274 www.pythian.com -- --
Re: DBD::Oracle v1.61_00 on its way to CPAN
The trial version has been promoted to 1.62 (changelog below) and is now on CPAN. 1.62 2013-04-30 - promote 1.61_00 to official release Thanks to everyone who contributed to this release! Michael -- *Michael Portnoy * Software Developer Pythian love your data www.pythian.com office:+1 613 565 8696 x 381 mobile : +1 613 325 3788 On Mon, Apr 15, 2013 at 3:41 PM, Yanick Champoux wrote: > > This one is a minor release (changelog's below). As usual, if no issue > is found with this trial version, it's going to be promoted to 1.62 and > stable in two weeks' time. > > 1.61_00 2013-04-15 > > [BUG FIXES] > - Adjust the privs needed for the DROP/CREATE table test. [GH#35] > (Joe Crotty) > > - Fixed RT84170 - when using scrollable cursors and you've done a > positioned fetch and then keep fetching until the end of the > result-set calls to fetch never return undef and you keep getting > the last row forever. Also added test case to the 51scroll.t test > (Martin J. Evans). > > > Enjoy, > `/anick > > -- > Yanick Champoux > Senior Perl Developer > Pythian - Love your data > > champ...@pythian.com > > Tel: +1 613 565 8696 x 274 > www.pythian.com > > > -- > > > -- > > > > -- --
Re: DBD::Oracle - rt13865.t
On 12/14/2012 03:52 AM, Martin J. Evans wrote:
On 13/12/12 17:46, Scott wrote:
Do you have the DROP ANY TABLE privilege set for the userid? That is
the only DROP TABLE priv I can see, so I probably need to have the
dba grant it to my install-test user.
I do have drop any table privilege as I have the DBA role.
Can't you just ignore that test?
Yes, I just wanted to report that the test works without out the check
for the DROP privileges.
Martin
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to
run. In Oracle, AFAIK, there is not a DROP TABLE privilege. If
you can create it, you can drop it. Does this test not run for
everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'}
) ){ #and ( $priv{'DROP TABLE'} or $priv{'DROP ANY
TABLE'} ) ) { plan skip_all => q{requires permissions 'CREATE
TABLE' and 'DROP TABLE'}; }
Scott
Works and runs for me:
$ prove -vb t/rt13865.t t/rt13865.t .. 1..9 ok 1 - INTEGER is alias
for NUMBER(38) ok 2 - NUMBER(37) ok 3 - NUMBER ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69) ok 6 - NVARCHAR2(69) ok 7 - NCHAR(69) ok 8 -
CHAR(67) ok 9 - CHAR(69) ok All tests successful. Files=1, Tests=9,
12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07 csys =
0.25 CPU) Result: PASS
Re: DBD::Oracle - rt13865.t
On 13/12/12 17:46, Scott wrote:
Do you have the DROP ANY TABLE privilege set for the userid? That is
the only DROP TABLE priv I can see, so I probably need to have the
dba grant it to my install-test user.
I do have drop any table privilege as I have the DBA role.
Can't you just ignore that test?
Martin
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to
run. In Oracle, AFAIK, there is not a DROP TABLE privilege. If
you can create it, you can drop it. Does this test not run for
everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'}
) ){ #and ( $priv{'DROP TABLE'} or $priv{'DROP ANY
TABLE'} ) ) { plan skip_all => q{requires permissions 'CREATE
TABLE' and 'DROP TABLE'}; }
Scott
Works and runs for me:
$ prove -vb t/rt13865.t t/rt13865.t .. 1..9 ok 1 - INTEGER is alias
for NUMBER(38) ok 2 - NUMBER(37) ok 3 - NUMBER ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69) ok 6 - NVARCHAR2(69) ok 7 - NCHAR(69) ok 8 -
CHAR(67) ok 9 - CHAR(69) ok All tests successful. Files=1, Tests=9,
12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07 csys =
0.25 CPU) Result: PASS
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Re: DBD::Oracle - rt13865.t
Do you have the DROP ANY TABLE privilege set for the userid?
That is the only DROP TABLE priv I can see, so I probably need to have
the dba grant it to my install-test user.
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to run.
In Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does
this test not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP
TABLE'};
}
Scott
Works and runs for me:
$ prove -vb t/rt13865.t
t/rt13865.t ..
1..9
ok 1 - INTEGER is alias for NUMBER(38)
ok 2 - NUMBER(37)
ok 3 - NUMBER
ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69)
ok 6 - NVARCHAR2(69)
ok 7 - NCHAR(69)
ok 8 - CHAR(67)
ok 9 - CHAR(69)
ok
All tests successful.
Files=1, Tests=9, 12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr
0.07 csys = 0.25 CPU)
Result: PASS
Re: DBD::Oracle - rt13865.t
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to run. In
Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does this test
not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP TABLE'};
}
Scott
Works and runs for me:
$ prove -vb t/rt13865.t
t/rt13865.t ..
1..9
ok 1 - INTEGER is alias for NUMBER(38)
ok 2 - NUMBER(37)
ok 3 - NUMBER
ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69)
ok 6 - NVARCHAR2(69)
ok 7 - NCHAR(69)
ok 8 - CHAR(67)
ok 9 - CHAR(69)
ok
All tests successful.
Files=1, Tests=9, 12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07
csys = 0.25 CPU)
Result: PASS
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Re: DBD::Oracle RTs a summary and request for help
On 26/06/2012 21:51, Richie wrote: On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :) and fixed in 10.2.0.2
Re: DBD::Oracle RTs a summary and request for help
On 27/06/12 09:01, Martin Hall wrote: On 26/06/2012 21:51, Richie wrote: On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :) and fixed in 10.2.0.2 Interesting Martin, as someone found it was fixed in 10.2.0.5 and broken in 10.2.0.4. See http://comments.gmane.org/gmane.comp.lang.perl.modules.dbi.general/16206 and that is what I documented. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Oracle RTs a summary and request for help
On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :)
Re: DBD::Oracle RTs a summary and request for help
On 26/06/2012 21:51, Richie wrote: On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :) Thanks. I have fixed it for now by assuming OCIPing is not defined in 10.2 for AIX. The code now says you need 11.2 on AIX for OCIPing. Merijn confirmed this worked. Martin
Re: DBD::Oracle RTs a summary and request for help
On 24/06/2012 13:26, H.Merijn Brand wrote: On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. I have AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb plus Oracle 10.2.0.1.0 I'll have a look later. maybe even today This one is fixed now - thanks to Merijn. Martin
Re: DBD::Oracle RTs a summary and request for help
On Sun, 24 Jun 2012 14:26:13 +0200, "H.Merijn Brand" wrote: > On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" > wrote: > > > https://rt.cpan.org/Ticket/Display.html?id=69059 > > Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: > > 0712-001 Symbol OCIPing was referenced > > I don't have access to AIX or an Oracle 10 and op gone quiet. > > I have > AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb > plus Oracle 10.2.0.1.0 > > I'll have a look later. maybe even today Test results added to ticket. Available now for help. (Will start xchat now) -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 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/
Re: DBD::Oracle RTs a summary and request for help
On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" wrote: > https://rt.cpan.org/Ticket/Display.html?id=69059 > Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: > 0712-001 Symbol OCIPing was referenced > I don't have access to AIX or an Oracle 10 and op gone quiet. I have AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb plus Oracle 10.2.0.1.0 I'll have a look later. maybe even today -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 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/
Re: DBD::Oracle v1.45_00 on its way to CPAN
On 12-06-22 12:15 PM, Jared Still wrote: Wow! Awesome effort by Martin. No kidding. He's a machine. Even possibly the answer to that age-old question: "what would be the result of downloading an OCI API to a T-800 memory dataset". Pure relentless awesomeness, that's what results. :-) Joy, `/anick
Re: DBD-Oracle 1.40
On Mon, 12 Mar 2012 16:02:46 -0400, Yanick Champoux wrote: > On 12-03-11 11:48 AM, H.Merijn Brand wrote: > > On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux > > wrote: > > > >> On 12-03-11 06:01 AM, H.Merijn Brand wrote: > >>> t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) > >>> Failed tests: 2-3 > >>> Non-zero exit status: 2 > >>> Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr > >>> 0.01 csys = 0.08 CPU) > >> > >>That's not good. I'll issue a patch Monday, and try to narrow down on > >> which versions of Oracle the fix for rt-74753 isn't working. > > > > Note these: > > > > t/23wide_db.t . skipped: Database character set is not Unicode > > t/23wide_db_8bit.t skipped: Database character set is not Unicode > > t/23wide_db_al32utf8.t skipped: Database character set is not Unicode > > I have a new trial version changing the test so that it doesn't run if > the db character set is not unicode. I'm at home today, so I can't run > my battery of tests before releasing, but if anyone feel like giving it > a whirl, the new version is at > > svn repo: > http://svn.perl.org/modules/dbd-oracle/branches/DBD-Oracle-1.41_00 > > git repo: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 % git clone https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 DBD-Oracle Cloning into 'DBD-Oracle'... fatal: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41/info/refs not found: did you run git update-server-info on the server? % git clone https://github.com/yanick/DBD-Oracle DBD-Oracle Cloning into 'DBD-Oracle'... remote: Counting objects: 4891, done. remote: Compressing objects: 100% (1461/1461), done. remote: Total 4891 (delta 3470), reused 4763 (delta 3344) Receiving objects: 100% (4891/4891), 18.37 MiB | 1.07 MiB/s, done. Resolving deltas: 100% (3470/3470), done. % cd DBD-Oracle % git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/cand-v1.41 remotes/origin/cand_1.32 remotes/origin/candidate_1.31_00 remotes/origin/clean-changelog remotes/origin/cpan-changes remotes/origin/dist-zilla remotes/origin/doc-grooming remotes/origin/documentation-rt72252 remotes/origin/longdouble remotes/origin/master remotes/origin/oraperl-warning remotes/origin/pod-test remotes/origin/releases remotes/origin/rt-73206-ora_charset remotes/origin/rt13865 remotes/origin/rt30133 remotes/origin/rt71343-compile9i remotes/origin/rt74753 % git co remotes/origin/cand-v1.41 -b cand-v1.41 Branch cand-v1.41 set up to track remote branch cand-v1.41 from origin. Switched to a new branch 'cand-v1.41' % perl Makefile.PL Using DBI 1.618 (for perl 5.014001 on x86_64-linux-ld) installed in /pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/auto/DBI/ Configuring DBD::Oracle for perl 5.014001 on linux (x86_64-linux-ld) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a linux, Ver#2.6 Using Oracle in /usr/lib/oracle/11.2/client64 : : % make : ccache cc -c -I/usr/include/oracle/11.2/client64 -I/pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/auto/DBI -fPIC -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"undef\" -DXS_VERSION=\"undef\" -fPIC "-I/pro/lib/perl5/5.14.1/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c dbdimp.c: In function ‘ora_db_login6’: dbdimp.c:765:5: warning: format ‘%d’ expects type ‘int’, but argument 12 has type ‘size_t’ dbdimp.c:765:5: warning: format ‘%d’ expects type ‘int’, but argument 14 has type ‘size_t’ : % make test PERL_DL_NONLAZY=1 /pro/bin/perl5.14.1 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00versions.t Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Invalid version format (version required) at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Compilation failed in require at t/00versions.t line 10. BEGIN failed--compilation aborted at t/00versions.t line 10. # Looks like your test exited with 2 before it could output anything. t/00versions.t Dubious, test returned 2 (wstat 512, 0x200) Failed 2/2 subtests > > > FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 > > All beyond 1.27 fail > > :-( I'll open a ticket on RT about that one. > > Joy, > `/anick -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http:/
Re: DBD-Oracle 1.40
On 12-03-11 11:48 AM, H.Merijn Brand wrote: On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux wrote: On 12-03-11 06:01 AM, H.Merijn Brand wrote: t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.08 CPU) That's not good. I'll issue a patch Monday, and try to narrow down on which versions of Oracle the fix for rt-74753 isn't working. Note these: t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t skipped: Database character set is not Unicode I have a new trial version changing the test so that it doesn't run if the db character set is not unicode. I'm at home today, so I can't run my battery of tests before releasing, but if anyone feel like giving it a whirl, the new version is at svn repo: http://svn.perl.org/modules/dbd-oracle/branches/DBD-Oracle-1.41_00 git repo: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 All beyond 1.27 fail :-( I'll open a ticket on RT about that one. Joy, `/anick
Re: DBD-Oracle 1.40
On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux wrote: > On 12-03-11 06:01 AM, H.Merijn Brand wrote: > > t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) > >Failed tests: 2-3 > >Non-zero exit status: 2 > > Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 > > csys = 0.08 CPU) > > > That's not good. I'll issue a patch Monday, and try to narrow down on > which versions of Oracle the fix for rt-74753 isn't working. Note these: t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t skipped: Database character set is not Unicode FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 All beyond 1.27 fail -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 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/
Re: DBD-Oracle 1.40
On 12-03-11 06:01 AM, H.Merijn Brand wrote: t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.08 CPU) That's not good. I'll issue a patch Monday, and try to narrow down on which versions of Oracle the fix for rt-74753 isn't working. Joy, `/anick
Re: DBD::Oracle v1.39_00 is out
On Mon, 27 Feb 2012 09:57:33 -0500, Yanick Champoux
wrote:
> On 02/27/12 02:02, H.Merijn Brand wrote:
> > On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
> > wrote:
> >
> > > [OTHERS]
> > > - change the shebang line of examples to the more modern '/usr/bin/env
> > > perl'
> >
> > Personally I really really hate this change
>
> Fair enough. This being said, I have to point out that the change
> is only on the scripts in the 'examples/' directory, which are not
> installed as part of the distro.
Understood, but IMHO we/you should not/never promote that usage
> > Perl has been configured to use $Config{startperl}. Use it!
>
> I'm not sure I understand how you would like me to use it. I know that,
> if we ask nicely, MakeMaker and Module::Build will change the shebang
> of scripts that are to be installed to the local location of perl, but
> typically things that are not to be installed are left alone.
In which case I wonder why this change was needed in the first place
> Do you propose that the example directory get munged as part of the
> 'perl Makefile.PL' stage?
No, only if these examples are installed as option from Makefile.PL
(many modules allow that)
> Or do you know of a static shebang that goes straight for
> $Config{startperl} ?
No. Maybe #!your_path_to_perl_here
would be the best option :)
Maybe I sounded too harsh in my previous mail, but in the end, that
ticket should just have been marked "rejected" with exactly the
explanation you just wrote here. If it does not install those scripts
from examples, *ANY* shebang line is valid
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 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/
Re: DBD::Oracle v1.39_00 is out
On 02/27/12 02:02, H.Merijn Brand wrote:
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
wrote:
>[OTHERS]
>- change the shebang line of examples to the more modern '/usr/bin/env
> perl'
Personally I really really hate this change
Fair enough. This being said, I have to point out that the change
is only on the scripts in the 'examples/' directory, which are not
installed as part of the distro.
Perl has been configured to use $Config{startperl}. Use it!
I'm not sure I understand how you would like me to use it. I know
that, if we ask nicely, MakeMaker and Module::Build will change the shebang of
scripts that are to be installed to the local location of perl, but typically
things that are not to be installed are left alone. Do you propose that the
example directory get munged as part of the 'perl Makefile.PL' stage? Or do you
know of a static shebang that goes straight for $Config{startperl} ?
Joy,
`/anick
--
Yanick Champoux, Senior Perl Developer
The Pythian Group - love your data
http://www.pythian.com
--
--
Pythian proud winner of Oracle North America Titan Award for Exadata
Solution...watch the video on pythian.com
Re: DBD::Oracle v1.39_00 is out
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
wrote:
> [OTHERS]
> - change the shebang line of examples to the more modern '/usr/bin/env
> perl'
> [RT74001]
Personally I really really hate this change
App::Ack was the first I noted to make this horrid change and I always
revert the shebang line to reflect my production perl
I (very) often work on "other" perls than the one that is installed and
to make testing these with modules (like DBI, DBD::Oracle and many many
more, I temporary change my $PATH to have the perl I am testing first
In that perl, App::Ack is NOT (yet) installed.
For some/many scripts, it doesn't really matter if the script is
installed or not, but for all scripts that invoke modules it *does*
matter.
I certainly do NOT see this change as "more modern"
Perl has been configured to use $Config{startperl}. Use it!
$ perl -V:startperl
startperl='#!/pro/bin/perl';
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 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/
Re: DBD::Oracle v1.39_00 is out
A new DBD::Oracle trial version is out and on its way to CPAN. It's a maintenance release with fairly minor bug fixes (full changelog below). As usual, the trial version will be soaked for 2 weeks and, pending issues, will be promoted to v1.40 for general consumption. Joy, `/anick 1.39_00 2012-02-24 [BUG FIXES] - TAF supports now conditional to presence of OCI_ATTR_TAF_ENABLED [RT73798] - detect broken Win32::TieRegistry (patch by Rafael Kitover (Caelum)) [RT74544] - PL/SQL out values were not utf8 encoded [RT74753] (Steve Baldwin + Martin J. Evans) [DOCUMENTATION] - Mention the release of Oracle Instant Client 64 bit which does not work on Lion. (Martin J. Evans) - fix DBD::Oracle::GetInfo blurb (patch by Julián Moreno Patiño) [rt74000] - fix typos. (patch by Julián Moreno Patiño) [rt73999] - add troubleshoot doc and diag for error with bequeather. [rt75263] [OTHERS] - change the shebang line of examples to the more modern '/usr/bin/env perl' [RT74001] -- -- Pythian proud winner of Oracle North America Titan Award for Exadata Solution...watch the video on pythian.com
Re: DBD::Oracle
Yanick Champoux wrote: > And just to keep things interesting, I've noticed that I forgot the > ending semi-colon that is in the test. But surely that won't-- > > $ perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 > > --make a difference... Ah, I can explain what's going on there. If you give Perl `system` a single argument, it looks at the contents of that string, and decides whether it's a "trivial" command. Trivial commands in this sense are, roughly, those that contain no awkward punctuation characters — which would imply that the command needs to be executed by a shell. If Perl thinks no shell is needed, it optimises by executing the command directly, saving a shell process. Otherwise, it passes the command to the appropriate shell as desired. In this case, if you do `system "exit 1;"`, the semicolon forces `system` to pass the command to a shell, and everything works as expected. On the other hand, `system "exit 1"` with no semicolon is executed directly. But there's no command named `exit` — it's a shell builtin (and has to be). So `system` is giving you the behaviour you get in the "command not found" case, namely a negative return value. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: DBD::Oracle
On Fri, Feb 10, 2012 at 07:03:09PM +0100, H.Merijn Brand wrote: > On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine > wrote: > > > >> If this reproduces the problem, you have something nothing to do > > >> with databases to investigate. If it doesn't reproduce the problem, > > >> it may be that Oracle is messing with the SIGCHLD signal. > > >> > > >> Are you connecting directly to the database using the bequeather? > > > > > > I've never heard of anything called a "bequeather" :) > > > > If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. > > This is the bequeather, which is the adapter used to connect to > > a local database when ORACLE_HOME and ORACLE_SID are specified > > and TWO_TASK is not. The BEQ adapter is inconsistent with the > > with perl built-ins which use fork or popen unless you put > > 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this > > sqlnet.ora option is not the default. > > All tests then pass I'm sure a patch to the docs, expressing the above, would be welcome. Tim.
Re: DBD::Oracle
On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine wrote: > >> If this reproduces the problem, you have something nothing to do > >> with databases to investigate. If it doesn't reproduce the problem, > >> it may be that Oracle is messing with the SIGCHLD signal. > >> > >> Are you connecting directly to the database using the bequeather? > > > > I've never heard of anything called a "bequeather" :) > > If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. > This is the bequeather, which is the adapter used to connect to > a local database when ORACLE_HOME and ORACLE_SID are specified > and TWO_TASK is not. The BEQ adapter is inconsistent with the > with perl built-ins which use fork or popen unless you put > 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this > sqlnet.ora option is not the default. All tests then pass -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 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/
Re: DBD::Oracle
On 10/02/12 14:56, H.Merijn Brand wrote:
> On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine
> wrote:
>
>> On 10/02/12 13:32, H.Merijn Brand wrote:
>>> Preparing a new database machine ...
>>>
>>> Do I need to worry?
>>> t/10general.t 1/30
>>> # Failed test 'system exit 1 should return 256'
>>> # at t/10general.t line 41.
>>> # got: '-1'
>>> # expected: '256'
>>>
>>> # Failed test 'system exit 0 should return 0'
>>> # at t/10general.t line 42.
>>> # got: '-1'
>>> # expected: '0'
>>> t/10general.t 3/30 # Looks like you failed 2 tests of 30.
>>> t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
>>
>> This symptom indicates that the system built-in function is not working.
>>
>> Try
>>
>> perl -e 'print system("exit 1;"), "\n"'
>
> $ perl -e 'print system("exit 1;"), "\n"'
> 256
>
>> If this reproduces the problem, you have something nothing to do
>> with databases to investigate. If it doesn't reproduce the problem,
>> it may be that Oracle is messing with the SIGCHLD signal.
>>
>> Are you connecting directly to the database using the bequeather?
>
> I've never heard of anything called a "bequeather" :)
If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'.
This is the bequeather, which is the adapter used to connect to
a local database when ORACLE_HOME and ORACLE_SID are specified
and TWO_TASK is not. The BEQ adapter is inconsistent with the
with perl built-ins which use fork or popen unless you put
'bequeath_detach = yes' in sqlnet.ora. It is a pity that this
sqlnet.ora option is not the default.
>> If so, try connecting via SQL*Net instead. If avoiding the bequeather
>> fixes the problem, try putting 'bequeath_detach = yes' in your
>> sqlnet.ora file. This should allow you to use the bequeather and
>> system at the same time.
>
> above test was without TWO_TASK. Using the listener, I get
>
> All tests successful.
> Files=35, Tests=2008, 31 wallclock secs ( 0.40 usr 0.04 sys + 3.69 cusr
> 1.28 csys = 5.41 CPU)
> Result: PASS
> PERL_DL_NONLAZY=1 /pro/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
>
>
--
Charles Jardine - Computing Service, University of Cambridge
c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
Re: DBD::Oracle
On Fri, Feb 10, 2012 at 04:29:07PM +0100, H.Merijn Brand wrote: > On Fri, 10 Feb 2012 10:22:20 -0500, Yanick Champoux > wrote: > > > On 02/10/12 09:56, Yanick Champoux wrote: > > > which should be okay, but I'm suddenly thinking: on some shells > > > 'exit' might not do what we would expect. Indeed, I just tried: > > > > > > $ perl -E'say system "exit 1"' > > > -1 > > > > And just to keep things interesting, I've noticed that I forgot the > > ending semi-colon that is in the test. But surely that won't-- > > > > $ perl -E'say system "exit 1"; say system "exit 1;"' > > -1 > > 256 > > % perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 > > > --make a difference... Uuuh, okay, I need to brush up my shell > > syntax skills. And should probably look into making that test slightly > > less shell-dependent. perldoc -f system says If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system’s command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient. Note that it's always /bin/sh on unix systems (it does't use SHELL env var). Tim.
Re: DBD::Oracle
On Fri, 10 Feb 2012 10:22:20 -0500, Yanick Champoux wrote: > On 02/10/12 09:56, Yanick Champoux wrote: > > which should be okay, but I'm suddenly thinking: on some shells > > 'exit' might not do what we would expect. Indeed, I just tried: > > > > $ perl -E'say system "exit 1"' > > -1 > > And just to keep things interesting, I've noticed that I forgot the > ending semi-colon that is in the test. But surely that won't-- > > $ perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 % perl -E'say system "exit 1"; say system "exit 1;"' -1 256 > --make a difference... Uuuh, okay, I need to brush up my shell > syntax skills. And should probably look into making that test slightly > less shell-dependent. > > Joy, > `/anick -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 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/
Re: DBD::Oracle
On 02/10/12 09:56, Yanick Champoux wrote: which should be okay, but I'm suddenly thinking: on some shells 'exit' might not do what we would expect. Indeed, I just tried: $ perl -E'say system "exit 1"' -1 And just to keep things interesting, I've noticed that I forgot the ending semi-colon that is in the test. But surely that won't-- $ perl -E'say system "exit 1"; say system "exit 1;"' -1 256 --make a difference... Uuuh, okay, I need to brush up my shell syntax skills. And should probably look into making that test slightly less shell-dependent. Joy, `/anick
Re: DBD::Oracle
On Fri, 10 Feb 2012 09:56:59 -0500, Yanick Champoux
wrote:
> On 02/10/12 09:30, Charles Jardine wrote:
> >> > t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
> > This symptom indicates that the system built-in function is not working.
> >
> > Try
> >
> > perl -e 'print system("exit 1;"), "\n"'
>
> Hmmm... The test that is failing is
>
> is system("exit 1;"), 1<<8, 'system exit 1 should return 256';
>
> which should be okay, but I'm suddenly thinking: on some shells
> 'exit' might not do what we would expect. Indeed, I just tried:
My shell is not what most people use:
% echo $SHELL $version
/pro/bin/tcsh tcsh 6.17.02 (Astron) 2010-05-12 (x86_64-unknown-linux) options
wide,nls,vi,kan,rh,color,ccat,filec,procura
% perl -E'say system "exit 1"'
-1
% perl -E'say system "exit 0"'
-1
% perl -E'say system "exit -1"'
-1
% echo $status
0
> $ perl -E'say system "exit 1"'
> -1
>
> And yet the tests usually pass on my machine. I have to look at
> that in more details...
>
> Joy,
> `/anick
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 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/
Re: DBD::Oracle
On 02/10/12 09:30, Charles Jardine wrote:
> t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
This symptom indicates that the system built-in function is not working.
Try
perl -e 'print system("exit 1;"), "\n"'
Hmmm... The test that is failing is
is system("exit 1;"), 1<<8, 'system exit 1 should return 256';
which should be okay, but I'm suddenly thinking: on some shells
'exit' might not do what we would expect. Indeed, I just tried:
$ perl -E'say system "exit 1"'
-1
And yet the tests usually pass on my machine. I have to look at
that in more details...
Joy,
`/anick
Re: DBD::Oracle
On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine
wrote:
> On 10/02/12 13:32, H.Merijn Brand wrote:
> > Preparing a new database machine ...
> >
> > Do I need to worry?
> > t/10general.t 1/30
> > # Failed test 'system exit 1 should return 256'
> > # at t/10general.t line 41.
> > # got: '-1'
> > # expected: '256'
> >
> > # Failed test 'system exit 0 should return 0'
> > # at t/10general.t line 42.
> > # got: '-1'
> > # expected: '0'
> > t/10general.t 3/30 # Looks like you failed 2 tests of 30.
> > t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
>
> This symptom indicates that the system built-in function is not working.
>
> Try
>
> perl -e 'print system("exit 1;"), "\n"'
$ perl -e 'print system("exit 1;"), "\n"'
256
> If this reproduces the problem, you have something nothing to do
> with databases to investigate. If it doesn't reproduce the problem,
> it may be that Oracle is messing with the SIGCHLD signal.
>
> Are you connecting directly to the database using the bequeather?
I've never heard of anything called a "bequeather" :)
> If so, try connecting via SQL*Net instead. If avoiding the bequeather
> fixes the problem, try putting 'bequeath_detach = yes' in your
> sqlnet.ora file. This should allow you to use the bequeather and
> system at the same time.
above test was without TWO_TASK. Using the listener, I get
All tests successful.
Files=35, Tests=2008, 31 wallclock secs ( 0.40 usr 0.04 sys + 3.69 cusr 1.28
csys = 5.41 CPU)
Result: PASS
PERL_DL_NONLAZY=1 /pro/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 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/
Re: DBD::Oracle
On 10/02/12 13:32, H.Merijn Brand wrote:
> Preparing a new database machine ...
>
> Do I need to worry?
> t/10general.t 1/30
> # Failed test 'system exit 1 should return 256'
> # at t/10general.t line 41.
> # got: '-1'
> # expected: '256'
>
> # Failed test 'system exit 0 should return 0'
> # at t/10general.t line 42.
> # got: '-1'
> # expected: '0'
> t/10general.t 3/30 # Looks like you failed 2 tests of 30.
> t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
This symptom indicates that the system built-in function is not working.
Try
perl -e 'print system("exit 1;"), "\n"'
If this reproduces the problem, you have something nothing to do
with databases to investigate. If it doesn't reproduce the problem,
it may be that Oracle is messing with the SIGCHLD signal.
Are you connecting directly to the database using the bequeather?
If so, try connecting via SQL*Net instead. If avoiding the bequeather
fixes the problem, try putting 'bequeath_detach = yes' in your
sqlnet.ora file. This should allow you to use the bequeather and
system at the same time.
--
Charles Jardine - Computing Service, University of Cambridge
c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
Re: DBD::Oracle v1.32 and v1.33_00 on their way to CPAN
On Tue, 18 Oct 2011 13:15:58 -0400, Yanick Champoux
wrote:
> Hi all,
>
> As no issue has been found with DBD::Oracle v1.31_00, it has been
> promoted to v1.32 and is on its way to CPAN.
With a perl configured with -Duselongdouble:
This is perl 5, version 14, subversion 1 (v5.14.1) built for i686-linux-64int-ld
Installing on a linux, Ver#2.6
Using Oracle in /usr/lib/oracle/11.2/client
DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR)
Oracle version 11.2.0.2 (11.2)
SQL*Plus: Release 11.2.0.2.0 Production on Fri Oct 21 16:48:54 2011
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
t/58object.t 5/65
# Failed test 'new: Row 1 column 2 object attributes'
# at t/58object.t line 177.
# Structures begin differing at:
# $got->[7] = '12345.6788'
# $expected->[7] = '12345.6789'
# Failed test 'new: Row 1 column 2 object attributes'
# at t/58object.t line 184.
# Structures begin differing at:
# $got->[7] = '777.6660054'
# $expected->[7] = '777.666'
# Failed test 'DBD::Oracle::Object->attr_hash'
# at t/58object.t line 199.
# Structures begin differing at:
# $got->{AMOUNT} = '777.6660054'
# $expected->{AMOUNT} = '777.666'
# Failed test 'DBD::Oracle::Object->attr'
# at t/58object.t line 200.
# Structures begin differing at:
# $got->{AMOUNT} = '777.6660054'
# $expected->{AMOUNT} = '777.666'
# Looks like you failed 4 tests of 65.
t/58object.t Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/65 subtests
Test Summary Report
---
t/58object.t (Wstat: 1024 Tests: 65 Failed: 4)
Failed tests: 41, 45, 47-48
Non-zero exit status: 4
Files=33, Tests=2525, 23 wallclock secs ( 0.42 usr 0.04 sys + 3.38 cusr 0.56
csys = 4.40 CPU)
Result: FAIL
Failed 1/33 test programs. 4/2525 subtests failed.
> Also, the next trial version v1.33_00 is also to appear in a few
> instants. The changelog is small and deal mostly with doc changes:
>
> Changes in DBD-Oracle 1.33_00 (18-10-2011)
>
> [BUG FIXES]
> - COLUMN_SIZE of VARCHAR2 returns size in chars, not bytes. [RT#13865]
> (reported by Stefano and Laurent Dami)
>
> [DOCUMENTATION]
> - add mention of the github mirror of the subversion repository
> - add 'resources' info to META.yml
> - fixed broken link to Oracle DRCP doc in POD (John Scoles)
>
>
> As usual, if you are so inclined, please test and provide feedback.
> Unless issues are found, this load should be promoted for general
> consumption in 2 weeks.
>
> Joy,
> `/anick
>
> --
> Pythian proud winner of Oracle North America Titan Award for Exadata
> Solution... Read more & see us at OpenWorld bit.ly/pythianoow11
>
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle Release Candidate 1
On 18/02/2011 4:12 AM, Charles Jardine wrote:
Ok that cleans that one up..
Hopefully I will have some time today to get to that one
Thanks
John
On 17/02/11 12:34, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip
You need to work on longdouble support I guess
I wrote the tests in question. I included object properties of type
DATE and NUMERIC to provide tests against regression of some changes
I had made to get_attr_val to fix type mismatches.
I realise that I made a mistake by using literal Perl floating point
numbers in the insert statements. Doing it this way means that, on
the route into Oracle, the number is converted first into Perl's binary
floating point format and then into Oracle's base-100 format.
(I was only interested in testing the route out of Oracle.)
I think the best fix is simply to use strings in the insert statements.
Change 12345.6789 to '12345.6789' and 777.666 to '777.666'. This
way, the conversions both ways will be done by Oracle. Conversion of
a decimal string representation to a base-100 representation of adequate
precision will be exact. Nothing will be hidden under the carpet.
I should have written it like this originally. I am sorry.
Here's a patch to make the test PASS on all systems, but I'm not sure
if I'm using a carpet to shuv the problems under ...
--- t/58object.t.org2011-02-17 13:33:48.0 +0100
+++ t/58object.t2011-02-17 13:33:25.0 +0100
@@ -82,9 +82,9 @@ $dbh->do(qq{ INSERT INTO $table VALUES (
or die $dbh->errstr;
$dbh->do(qq{ INSERT INTO $table VALUES (2, $sub_type(NULL, 'obj2',
TO_DATE('2004-11-30 14:27:18', '-MM-DD
HH24:MI:SS'),
-12345.6789)) }
+12345.9375)) }
) or die $dbh->errstr;
-$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3',
NULL, 777.666)) }
+$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3',
NULL, 777.875)) }
) or die $dbh->errstr;
$dbh->do(qq{ CREATE OR REPLACE TYPE $inner_type AS OBJECT (
@@ -159,14 +159,14 @@ ok (scalar @row2, 'new: Fetch second row
cmp_ok(ref $row2[1], 'eq', 'DBD::Oracle::Object', 'new: Row 2
column 2 is an DBD::Oracle::Object');
cmp_ok(uc $row2[1]->type_name, "eq", uc "$schema.$sub_type", "new:
Row 2 column 2 object type");
is_deeply([$row2[1]->attributes], ['NUM', undef, 'NAME', 'obj2',
-'DATETIME', '2004-11-30T14:27:18', 'AMOUNT',
'12345.6789'], "new: Row 1 column 2 object attributes");
+'DATETIME', '2004-11-30T14:27:18', 'AMOUNT',
'12345.9375'], "new: Row 1 column 2 object attributes");
@row3 = $sth->fetchrow();
ok (scalar @row3, 'new: Fetch third row');
cmp_ok(ref $row3[1], 'eq', 'DBD::Oracle::Object', 'new: Row 3
column 2 is an DBD::Oracle::Object');
cmp_ok(uc $row3[1]->type_name, "eq", uc "$schema.$sub_type", "new:
Row 3 column 2 object type");
is_deeply([$row3[1]->attributes], ['NUM', 5, 'NAME', 'obj3',
-'DATETIME', undef, 'AMOUNT', '777.666'], "new: Row 1
column 2 object attributes");
+'DATETIME', undef, 'AMOUNT', '777.875'], "new: Row 1
column 2 object attributes");
ok (!$sth->fetchrow(), 'new: No more rows expected');
@@ -178,7 +178,7 @@ my $expected_hash = {
NUM => 5,
NAME=> 'obj3',
DATETIME=> undef,
-AMOUNT => 777.666,
+AMOUNT => 777.875,
};
is_deeply($obj->attr_hash, $expected_hash,
'DBD::Oracle::Object->attr_hash');
is_deeply($obj->attr, $expected_hash, 'DBD::Oracle::Object->attr');
Re: DBD::Oracle Release Candidate 1
On 17/02/11 12:34, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip
You need to work on longdouble support I guess
I wrote the tests in question. I included object properties of type
DATE and NUMERIC to provide tests against regression of some changes
I had made to get_attr_val to fix type mismatches.
I realise that I made a mistake by using literal Perl floating point
numbers in the insert statements. Doing it this way means that, on
the route into Oracle, the number is converted first into Perl's binary
floating point format and then into Oracle's base-100 format.
(I was only interested in testing the route out of Oracle.)
I think the best fix is simply to use strings in the insert statements.
Change 12345.6789 to '12345.6789' and 777.666 to '777.666'. This
way, the conversions both ways will be done by Oracle. Conversion of
a decimal string representation to a base-100 representation of adequate
precision will be exact. Nothing will be hidden under the carpet.
I should have written it like this originally. I am sorry.
Here's a patch to make the test PASS on all systems, but I'm not sure
if I'm using a carpet to shuv the problems under ...
--- t/58object.t.org2011-02-17 13:33:48.0 +0100
+++ t/58object.t2011-02-17 13:33:25.0 +0100
@@ -82,9 +82,9 @@ $dbh->do(qq{ INSERT INTO $table VALUES (
or die $dbh->errstr;
$dbh->do(qq{ INSERT INTO $table VALUES (2, $sub_type(NULL, 'obj2',
TO_DATE('2004-11-30 14:27:18', '-MM-DD HH24:MI:SS'),
-12345.6789)) }
+12345.9375)) }
) or die $dbh->errstr;
-$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.666)) }
+$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.875)) }
) or die $dbh->errstr;
$dbh->do(qq{ CREATE OR REPLACE TYPE $inner_type AS OBJECT (
@@ -159,14 +159,14 @@ ok (scalar @row2, 'new: Fetch second row
cmp_ok(ref $row2[1], 'eq', 'DBD::Oracle::Object', 'new: Row 2 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row2[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 2 column 2
object type");
is_deeply([$row2[1]->attributes], ['NUM', undef, 'NAME', 'obj2',
-'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.6789'], "new: Row 1
column 2 object attributes");
+'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.9375'], "new: Row 1
column 2 object attributes");
@row3 = $sth->fetchrow();
ok (scalar @row3, 'new: Fetch third row');
cmp_ok(ref $row3[1], 'eq', 'DBD::Oracle::Object', 'new: Row 3 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row3[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 3 column 2
object type");
is_deeply([$row3[1]->attributes], ['NUM', 5, 'NAME', 'obj3',
-'DATETIME', undef, 'AMOUNT', '777.666'], "new: Row 1 column 2 object
attributes");
+'DATETIME', undef, 'AMOUNT', '777.875'], "new: Row 1 column 2 object
attributes");
ok (!$sth->fetchrow(), 'new: No more rows expected');
@@ -178,7 +178,7 @@ my $expected_hash = {
NUM => 5,
NAME=> 'obj3',
DATETIME=> undef,
-AMOUNT => 777.666,
+AMOUNT => 777.875,
};
is_deeply($obj->attr_hash, $expected_hash, 'DBD::Oracle::Object->attr_hash');
is_deeply($obj->attr, $expected_hash, 'DBD::Oracle::Object->attr');
--
Charles Jardine - Computing Service, University of Cambridge
c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
Re: DBD::Oracle Release Candidate 1
On 16/02/11 11:32, H.Merijn Brand wrote: On Fri, 11 Feb 2011 13:43:34 -0500, John Scoles wrote: Here is the latest and greatest DBD::Oracle for your programming pleasure. You can find the Zip file here A ZIP is a quite unusual way to release CPAN modules, even for RC's http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip You need to work on longdouble support I guess Sorry for the long mail. I think it contains a lot of info to digest :) A summary for a few boxes ... Like Merijn I also get 31lob failures on linux 64 bit. I was using database 11.1.0.6.0 and Instant Client11.2.0.2.0. Results below. Also, if line 1735 of oci8.c is changed to: PerlIO_printf(DBILOGFP, " blob_read field %d, ftype %d, offset %ld, len %lu, destoffset %ld, retlen %lu\n", fbh->field_num+1, ftype, offset, (unsigned long)len, destoffset, ul_t(amtp)); it makes a legitimate warning go away. t/31lob1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value not ok 9 - returned length via PL/SQL # Failed test 'returned length via PL/SQL' # at t/31lob.t line 152. # got: undef # expected: '4' Errors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x000A8C6D8], [0], [0], [0], [], [], [] `8<��Z��S+Z��S+Z��S+0:<��0:<��0:<��0:<��0:<��0:<��0:<��0:<��Errors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x000A8C6D8], [0], [0], [0], [], [], [] P:<��Z��S+Z��S+Z��S+ <<�� <<�� <<�� <<�� <<�� <<�� <<�� <<��dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED tests 9-12 Failed 4/12 tests, 66.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/31lob.t 1 256127 58.33% 9-12 Failed 1/1 test scripts, 0.00% okay. 4/12 subtests failed, 66.67% okay. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Oracle Release Candidate 1
On 17/02/2011 7:34 AM, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip
You need to work on longdouble support I guess
Here's a patch to make the test PASS on all systems, but I'm not sure
if I'm using a carpet to shuv the problems under ...
Yep I think that is exactly what you are doing.
I will have to look exactly at this to see what is going in but your
test and the code below will help
Will get back to you soon
I hope
Cheers
John
--- t/58object.t.org2011-02-17 13:33:48.0 +0100
+++ t/58object.t2011-02-17 13:33:25.0 +0100
@@ -82,9 +82,9 @@ $dbh->do(qq{ INSERT INTO $table VALUES (
or die $dbh->errstr;
$dbh->do(qq{ INSERT INTO $table VALUES (2, $sub_type(NULL, 'obj2',
TO_DATE('2004-11-30 14:27:18', '-MM-DD HH24:MI:SS'),
-12345.6789)) }
+12345.9375)) }
) or die $dbh->errstr;
-$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.666)) }
+$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.875)) }
) or die $dbh->errstr;
$dbh->do(qq{ CREATE OR REPLACE TYPE $inner_type AS OBJECT (
@@ -159,14 +159,14 @@ ok (scalar @row2, 'new: Fetch second row
cmp_ok(ref $row2[1], 'eq', 'DBD::Oracle::Object', 'new: Row 2 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row2[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 2 column 2
object type");
is_deeply([$row2[1]->attributes], ['NUM', undef, 'NAME', 'obj2',
-'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.6789'], "new: Row 1
column 2 object attributes");
+'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.9375'], "new: Row 1
column 2 object attributes");
@row3 = $sth->fetchrow();
ok (scalar @row3, 'new: Fetch third row');
cmp_ok(ref $row3[1], 'eq', 'DBD::Oracle::Object', 'new: Row 3 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row3[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 3 column 2
object type");
is_deeply([$row3[1]->attributes], ['NUM', 5, 'NAME', 'obj3',
-'DATETIME', undef, 'AMOUNT', '777.666'], "new: Row 1 column 2 object
attributes");
+'DATETIME', undef, 'AMOUNT', '777.875'], "new: Row 1 column 2 object
attributes");
ok (!$sth->fetchrow(), 'new: No more rows expected');
@@ -178,7 +178,7 @@ my $expected_hash = {
NUM => 5,
NAME=> 'obj3',
DATETIME=> undef,
-AMOUNT => 777.666,
+AMOUNT => 777.875,
};
is_deeply($obj->attr_hash, $expected_hash, 'DBD::Oracle::Object->attr_hash');
is_deeply($obj->attr, $expected_hash, 'DBD::Oracle::Object->attr');
Re: DBD::Oracle Release Candidate 1
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
> http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip
>
> You need to work on longdouble support I guess
Here's a patch to make the test PASS on all systems, but I'm not sure
if I'm using a carpet to shuv the problems under ...
--- t/58object.t.org2011-02-17 13:33:48.0 +0100
+++ t/58object.t2011-02-17 13:33:25.0 +0100
@@ -82,9 +82,9 @@ $dbh->do(qq{ INSERT INTO $table VALUES (
or die $dbh->errstr;
$dbh->do(qq{ INSERT INTO $table VALUES (2, $sub_type(NULL, 'obj2',
TO_DATE('2004-11-30 14:27:18', '-MM-DD HH24:MI:SS'),
-12345.6789)) }
+12345.9375)) }
) or die $dbh->errstr;
-$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.666)) }
+$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.875)) }
) or die $dbh->errstr;
$dbh->do(qq{ CREATE OR REPLACE TYPE $inner_type AS OBJECT (
@@ -159,14 +159,14 @@ ok (scalar @row2, 'new: Fetch second row
cmp_ok(ref $row2[1], 'eq', 'DBD::Oracle::Object', 'new: Row 2 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row2[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 2
column 2 object type");
is_deeply([$row2[1]->attributes], ['NUM', undef, 'NAME', 'obj2',
-'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.6789'], "new:
Row 1 column 2 object attributes");
+'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.9375'], "new:
Row 1 column 2 object attributes");
@row3 = $sth->fetchrow();
ok (scalar @row3, 'new: Fetch third row');
cmp_ok(ref $row3[1], 'eq', 'DBD::Oracle::Object', 'new: Row 3 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row3[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 3
column 2 object type");
is_deeply([$row3[1]->attributes], ['NUM', 5, 'NAME', 'obj3',
-'DATETIME', undef, 'AMOUNT', '777.666'], "new: Row 1 column 2
object attributes");
+'DATETIME', undef, 'AMOUNT', '777.875'], "new: Row 1 column 2
object attributes");
ok (!$sth->fetchrow(), 'new: No more rows expected');
@@ -178,7 +178,7 @@ my $expected_hash = {
NUM => 5,
NAME=> 'obj3',
DATETIME=> undef,
-AMOUNT => 777.666,
+AMOUNT => 777.875,
};
is_deeply($obj->attr_hash, $expected_hash, 'DBD::Oracle::Object->attr_hash');
is_deeply($obj->attr, $expected_hash, 'DBD::Oracle::Object->attr');
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle Release Candidate 1
On 16/02/11 12:00, John Scoles wrote:
On Wed, Feb 16, 2011 at 5:45 AM, Martin J. Evans
wrote:
On 11/02/11 18:43, John Scoles wrote:
Here is the latest and greatest DBD::Oracle for your programming pleasure.
You can find the Zip file here
http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip
This is a long overdue maintenance release that fixes a large number of
bug and issues which are detailed below in the Changes.
Don't worry there are some new goodies in this release namely I have added
in 4 new
server side tracing/debugging attributes
ora_driver_name
For 11g and later you can now set the name of the driver layer using OCI.
PERL, PERL5, ApachePerl so on. Names starting with "ORA" are reserved. You
can enter up to 8 characters. If none is enter then this will default to
DBDO where is the current version number. This value can be
retrieved on the server side using V$SESSION_CONNECT_INFO or
GV$SESSION_CONNECT_INFO
ora_client_info
When passed in on the connection attributes it can specify any info you
want
onto the session up t0 64 bytes. This value can be
retrieved on the server side using V$SESSION view.
ora_client_identifier
When passed in on the connection attributes it specifies the user
identifier
in the session handle. Most useful for web app as it can pass in the
session
user name which might be different than the connection user name. Can be
up
to 64 bytes long do not to include the password for security reasons and
the
first character of the identifier should not be ':'. This value can be
retrieved on the server side using V$SESSION view.
ora_action
You can set this value to anything you want up to 32byes.This value can be
retrieved on the server side using V$SESSION view.
We have also added in the connection attribute
ora_connect_with_default_signals
Whit this attribute you can localize the $SIG{} so this should solve the
problems with $SIG{} events that sometimes occur when using DBD::Oracle
Finally I would like to thank Martin Evans for volunteering to be another
co-maintainer of DBD::Oracle
Cheers
John Scoles
Changes
Added connection attribute 'ora_connect_with_default_signals' that will
localize Perl's $SIG{INT} handler from Brian Phillips and T. Bunce
Fix in execute_array to stop possible endless loop when using a fetch sub
by Martin J. Evans
Adapted Martin J. Evans' ODBC 70execute_array.t into t/26exe_array.t by
John Scoles
Fix for execute_array to bring it up to spec. by Martin J. Evans and John
Scoles
Marked ProC, Oraperl.pm, ora_explain.pl, ora_context,
ora_use_proc_connection and ora_parse_lang as deprecated to be removed in
1.29
Added in 4 new server side debug/trace attributes, ora_driver_name,
ora_client_info, ora_session_user and ora_action on the connection handle
from John Scoles
Cleaned up the pod a little by John Scoles
Fix for function name length, Some function names are over 31char long
which may cause problems for some OS/Compilers (VMS IA64 box.) from Jakob
Snoer
Fix for OCIPing in case where a 10 client tries to ping a<10 DB from
Tim Oertel
Fix for DBD-Oracle stored proc with array bug where second call array size
is unchanged from Tim Oertel
Fix for rt.cpan.org Ticket #=63332: Spelling error in POD from jonasbn
Fix for rt.cpan.org Ticket #=62152: t/28array_bind.t and t/31lob.t may
call plan() twice and others do not fail on not connect from John Scoles
Fix for rt.cpan.org Ticket #=61511 ORA-00942 when inserting into a table
with a LOB column over a synonym on HP-UX from Kris Lemaire
Fix for rt.cpan.org Ticket #=42842 Test 31lob fails with 64-bit Instant
Client by John Scoles
Fix for support for objects on big endian platforms from Charles Jardine,
John R Pierce
Fix for rt.cpan.org Ticket #=61225 Windows install (Stawberry Perl) fails
on long path names from David Tulloh
Fix for rt.cpan.org Ticket #=rt64524 Memory Leak when Oracle connection
fails by Martin J. Evans
Added all the missing ora_drcp values to dbh private_attribute_info by
Martin J. Evans
Removed a load of attributes from sth private_attribute_info which are not
handle attributes but attributes to bind_param/prepare by Martin J. Evans
Fix for rt.cpan.org Ticket #=64244 - don't bail out, skip tests when
we cannot connect by Martin J. Evans and John Scoles
Added DBI to PREREQ_PM in Makefile.PL by Martin J. Evans
Added build_requires in Makefile.PL by Martin J. Evans
Added workaround for ExtUtils::MakeMaker problems by Martin J. Evans
Added LICENSE to Makefile.PL by Martin J. Evans
Cheers John Scoles
Thanks John.
I haven't had a chance to play with this release candidate properly until
today - sorry.
On the platforms I've tested on so far (a few Linuxes) I am getting 100%
test success.
I will upgrade our test system to this RC later to see if it finds any
problems.
The only problems I've found so far:
o the META.yml has not been generated properly (e.g., it is missing
build_required, configure_requires etc
o the version is still
Re: DBD::Oracle Release Candidate 1
On Wed, Feb 16, 2011 at 5:45 AM, Martin J. Evans
wrote:
> On 11/02/11 18:43, John Scoles wrote:
>>
>> Here is the latest and greatest DBD::Oracle for your programming pleasure.
>>
>> You can find the Zip file here
>>
>> > href="http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip
>>
>> This is a long overdue maintenance release that fixes a large number of
>> bug and issues which are detailed below in the Changes.
>>
>> Don't worry there are some new goodies in this release namely I have added
>> in 4 new
>> server side tracing/debugging attributes
>>
>> ora_driver_name
>> For 11g and later you can now set the name of the driver layer using OCI.
>> PERL, PERL5, ApachePerl so on. Names starting with "ORA" are reserved. You
>> can enter up to 8 characters. If none is enter then this will default to
>> DBDO where is the current version number. This value can be
>> retrieved on the server side using V$SESSION_CONNECT_INFO or
>> GV$SESSION_CONNECT_INFO
>>
>> ora_client_info
>> When passed in on the connection attributes it can specify any info you
>> want
>> onto the session up t0 64 bytes. This value can be
>> retrieved on the server side using V$SESSION view.
>>
>> ora_client_identifier
>> When passed in on the connection attributes it specifies the user
>> identifier
>> in the session handle. Most useful for web app as it can pass in the
>> session
>> user name which might be different than the connection user name. Can be
>> up
>> to 64 bytes long do not to include the password for security reasons and
>> the
>> first character of the identifier should not be ':'. This value can be
>> retrieved on the server side using V$SESSION view.
>>
>> ora_action
>> You can set this value to anything you want up to 32byes.This value can be
>> retrieved on the server side using V$SESSION view.
>>
>> We have also added in the connection attribute
>>
>> ora_connect_with_default_signals
>>
>> Whit this attribute you can localize the $SIG{} so this should solve the
>> problems with $SIG{} events that sometimes occur when using DBD::Oracle
>>
>>
>> Finally I would like to thank Martin Evans for volunteering to be another
>> co-maintainer of DBD::Oracle
>>
>>
>>
>> Cheers
>> John Scoles
>>
>>
>> Changes
>> Added connection attribute 'ora_connect_with_default_signals' that will
>> localize Perl's $SIG{INT} handler from Brian Phillips and T. Bunce
>> Fix in execute_array to stop possible endless loop when using a fetch sub
>> by Martin J. Evans
>> Adapted Martin J. Evans' ODBC 70execute_array.t into t/26exe_array.t by
>> John Scoles
>> Fix for execute_array to bring it up to spec. by Martin J. Evans and John
>> Scoles
>> Marked ProC, Oraperl.pm, ora_explain.pl, ora_context,
>> ora_use_proc_connection and ora_parse_lang as deprecated to be removed in
>> 1.29
>> Added in 4 new server side debug/trace attributes, ora_driver_name,
>> ora_client_info, ora_session_user and ora_action on the connection handle
>> from John Scoles
>> Cleaned up the pod a little by John Scoles
>> Fix for function name length, Some function names are over 31char long
>> which may cause problems for some OS/Compilers (VMS IA64 box.) from Jakob
>> Snoer
>> Fix for OCIPing in case where a 10 client tries to ping a <10 DB from
>> Tim Oertel
>> Fix for DBD-Oracle stored proc with array bug where second call array size
>> is unchanged from Tim Oertel
>> Fix for rt.cpan.org Ticket #=63332: Spelling error in POD from jonasbn
>> Fix for rt.cpan.org Ticket #=62152: t/28array_bind.t and t/31lob.t may
>> call plan() twice and others do not fail on not connect from John Scoles
>> Fix for rt.cpan.org Ticket #=61511 ORA-00942 when inserting into a table
>> with a LOB column over a synonym on HP-UX from Kris Lemaire
>> Fix for rt.cpan.org Ticket #=42842 Test 31lob fails with 64-bit Instant
>> Client by John Scoles
>> Fix for support for objects on big endian platforms from Charles Jardine,
>> John R Pierce
>> Fix for rt.cpan.org Ticket #=61225 Windows install (Stawberry Perl) fails
>> on long path names from David Tulloh
>> Fix for rt.cpan.org Ticket #=rt64524 Memory Leak when Oracle connection
>> fails by Martin J. Evans
>> Added all the missing ora_drcp values to dbh private_attribute_info by
>> Martin J. Evans
>> Removed a load of attributes from sth private_attribute_info which are not
>> handle attributes but attributes to bind_param/prepare by Martin J. Evans
>> Fix for rt.cpan.org Ticket #=64244 - don't bail out, skip tests when
>> we cannot connect by Martin J. Evans and John Scoles
>> Added DBI to PREREQ_PM in Makefile.PL by Martin J. Evans
>> Added build_requires in Makefile.PL by Martin J. Evans
>> Added workaround for ExtUtils::MakeMaker problems by Martin J. Evans
>> Added LICENSE to Makefile.PL by Martin J. Evans
>>
>> Cheers John Scoles
>
> Thanks John.
>
> I haven't had a chance to play with this release candidate properly until
> today - sorry.
>
> On the platforms I've tested on so far (a few Linuxe
Re: DBD::Oracle Release Candidate 1
On Fri, 11 Feb 2011 13:43:34 -0500, John Scoles
wrote:
> Here is the latest and greatest DBD::Oracle for your programming pleasure.
>
> You can find the Zip file here
>
> href="http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip
Next to the failures for longdouble, here's a fix for Oracle9:
http://www.xs4all.nl/~procura/DO-128.diff
/pro/bin/perl -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/ora_explain
PERL_DL_NONLAZY=1 /pro/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/01base.t .. # Test loading DBI, DBD::Oracle and version
t/01base.t .. ok
t/10general.t ... ok
t/12impdata.t ... ok
t/14threads.t ... skipped: this hpux perl 5.010001 not configured to
support iThreads
t/15nls.t ... ok
t/20select.t ok
t/21nchar.t . ok
t/22nchar_al32utf8.t ok
t/22nchar_utf8.t ok
t/23wide_db.t ... skipped: Database character set is not Unicode
t/23wide_db_8bit.t .. skipped: Database character set is not Unicode
t/23wide_db_al32utf8.t .. skipped: Database character set is not Unicode
t/24implicit_utf8.t . 1/74
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
t/24implicit_utf8.t . 38/74
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
t/24implicit_utf8.t . Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/74 subtests
t/25plsql.t . ok
t/26exe_array.t . ok
t/28array_bind.t ok
t/30long.t .. ok
t/31lob.t ... ok
t/31lob_extended.t .. ok
t/32xmltype.t ... ok
t/34pres_lobs.t . ok
t/40ph_type.t ... 1/19 Placeholder behaviour for ora_type=1 VARCHAR2
(the default) varies with Oracle version.
Oracle 7 didn't strip trailing spaces, Oracle 8 did, until 9.2.x
Your system doesn't. If that seems odd, let us know.
t/40ph_type.t ... ok
t/50cursor.t ok
t/51scroll.t ok
t/55nested.t ok
t/56embbeded.t .. ok
t/58object.t ok
t/60reauth.t skipped: ORACLE_USERID_2 not defined.
t/70meta.t .. ok
t/80ora_charset.t ... skipped: Database is set up as US7ASCII
Test Summary Report
---
t/24implicit_utf8.t (Wstat: 1024 Tests: 74 Failed: 4)
Failed tests: 33-34, 70-71
Non-zero exit status: 4
Files=30, Tests=2512, 47 wallclock secs ( 1.43 usr 0.23 sys + 23.53 cusr 2.79
csys = 27.98 CPU)
Result: FAIL
Failed 1/30 test programs. 4/2512 subtests failed.
DBD-Oracle-1.28_RC_2 > prove -vwb t/24implicit_utf8.t
t/24implicit_utf8.t ..
1..74
# --- testing implicit csform (dbhimp.c sets csform implicitly)
# row: 1: nice_string=\x03 byte_string=3 (, '.')
# row: 2: nice_string=a byte_string=97 (a, 'a')
# row: 3: nice_string=b byte_string=98 (b, 'b')
# row: 4: nice_string=\x{263A} byte_string=9786 (☺, "âº")
# --- testing with NLS_NCHAR=UTF8
# set $ENV{NLS_NCHAR}=UTF8
# Database 9.2.0.8.0 CHAR set is US7ASCII (Non-Unicode), NCHAR set is AL16UTF16
(Unicode)
# Client 9.2.0.8 NLS_LANG is '', NLS_NCHAR is 'UTF8'
ok 1 - prepared: insert into dbd_ora__drop_me ( idx, nch, descr, dt ) values(
?, ?, ?, sysdate )
ok 2 - bind_param idx
ok 3 - bind_param nch
ok 4 - bind_param descr withOUT attribute ora_csform
# create table dbd_ora__drop_me ( idx integer, nch nvarchar2(20), descr
varchar2(50), dt date )
ok 5 - insert row 1: control-C
ok 6 - bind_param idx
ok 7 - bind_param nch
ok 8 - bind_param descr withOUT attribute ora_csform
ok 9 - insert row 2: lowercase a
ok 10 - bind_param idx
ok 11 - bind_param nch
ok 12 - bind_param descr withOUT attribute ora_csform
ok 13 - insert row 3: lowercase b
ok 14 - bind_param idx
ok 15 - bind_param nch
ok 16 - bind_param descr withOUT attribute ora_csform
ok 17 - insert row 4: smiley face
ok 18 - prepared: select nch, descr, DUMP(nch), dt from dbd_ora__drop_me order
by idx
ok 19 - bind column nch
ok 20 - bind column descr
ok 21 - byte_string test of row 1: column: nch (uft8) control-C
ok 22 - nice_string test of row 1: column: nch (uft8) control-C
ok 23 - byte_string test of row 1: column: descr control-C
ok 24 - nice_string test of row 1: column: descr control-C
ok 25 - byte_string test of row 2: column: nch (uft8) lowercase a
ok 26 - nice_string test of row 2: column: nch (uft8) lowercase a
ok 27 - byte_string test of row 2: column: descr lowercase a
ok 28 - nice_string test of row 2: column: descr lowercase a
ok 29 - byte_string test of row 3: column: nch (uft8) lowercase b
ok 30 - nice_string test of row 3: column: nch (uft8) lowercase b
ok 31 - byte_string test of row 3: column: descr lowercase b
ok 32 - nice_string test of row 3: column: descr lowercase b
not ok 33 - byte_string test of row 4: column: nch (uft8) smiley face
not ok 34 - nice_string test of row 4: column: nch (uft8) smiley face
ok 35 - byte_string test of row 4: column: descr smiley face
ok 36 - nice_string test of row 4: c
Re: DBD::Oracle Release Candidate 1
On Fri, 11 Feb 2011 13:43:34 -0500, John Scoles wrote: > Here is the latest and greatest DBD::Oracle for your programming pleasure. > > You can find the Zip file here A ZIP is a quite unusual way to release CPAN modules, even for RC's > href="http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip You need to work on longdouble support I guess Sorry for the long mail. I think it contains a lot of info to digest :) A summary for a few boxes ... ## 1. Linux 2.6.31.14-0.4-default/#1 HP xw6400 Xeon(R) CPU E5320 @1.86GHz/1596(4) x86_64 Using DBI 1.616 (for perl 5.010001 on x86_64-linux) installed in /pro/lib/perl5/site_perl/5.10.1/x86_64-linux/auto/DBI/ Configuring DBD::Oracle for perl 5.010001 on linux (x86_64-linux) Installing on a linux, Ver#2.6 Using Oracle in /pro/oracle/v11.2 DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR) Oracle version 11.2.0.2 (11.2) Found /usr/share/oracle/11.2/client64/demo.mk Using /usr/share/oracle/11.2/client64/demo.mk Your LD_LIBRARY_PATH env var is set to '/pro/asql/o90G/bin:/pro/asql/o90G/lib:/usr/lib64:/usr/lib:/pro/oracle/v11.2/lib' Reading /usr/share/oracle/11.2/client64/demo.mk Found header files in /usr/include/oracle/11.2/client64. client_version=11.2 DBD-Oracle-1.28_RC_1 > make test PERL_DL_NONLAZY=1 /pro/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/01base.t .. # Test loading DBI, DBD::Oracle and version t/01base.t .. ok t/10general.t ... ok t/12impdata.t ... ok t/14threads.t ... skipped: this linux perl 5.010001 not configured to support iThreads t/15nls.t ... ok t/20select.t ok t/21nchar.t . ok t/22nchar_al32utf8.t ok t/22nchar_utf8.t ok t/23wide_db.t ... skipped: Database character set is not Unicode t/23wide_db_8bit.t .. skipped: Database character set is not Unicode t/23wide_db_al32utf8.t .. skipped: Database character set is not Unicode t/24implicit_utf8.t . ok t/25plsql.t . ok t/26exe_array.t . ok t/28array_bind.t ok t/30long.t .. ok t/31lob.t ... 2/12 t/31lob.t ... Dubious, test returned 1 (wstat 256, 0x100) Failed 4/12 subtests t/31lob_extended.t .. ok t/32xmltype.t ... ok t/34pres_lobs.t . ok t/40ph_type.t ... 1/19 Placeholder behaviour for ora_type=1 VARCHAR2 (the default) varies with Oracle version. Oracle 7 didn't strip trailing spaces, Oracle 8 did, until 9.2.x Your system doesn't. If that seems odd, let us know. t/40ph_type.t ... ok t/50cursor.t ok t/51scroll.t ok t/55nested.t ok t/56embbeded.t .. ok t/58object.t ok t/60reauth.t skipped: ORACLE_USERID_2 not defined. t/70meta.t .. ok t/80ora_charset.t ... skipped: Database is set up as US7ASCII Test Summary Report --- t/31lob.t (Wstat: 256 Tests: 9 Failed: 1) Failed test: 9 Non-zero exit status: 1 Parse errors: Bad plan. You planned 12 tests but ran 9. Files=30, Tests=2509, 25 wallclock secs ( 0.61 usr 0.08 sys + 5.44 cusr 0.97 csys = 7.10 CPU) Result: FAIL Failed 1/30 test programs. 1/2509 subtests failed. make: *** [test_dynamic] Error 255 DBD-Oracle-1.28_RC_1 > prove -vwb t/31lob.t t/31lob.t .. 1..12 ok 1 - returned valid locator ok 2 - inserted into BLOB successfully ok 3 - got back what we put in ok 4 - returned valid locator ok 5 - returned valid locator ok 6 - returned initialized locator ok 7 - returned length ok 8 - returned written value not ok 9 - returned length via PL/SQL # Failed test 'returned length via PL/SQL' # at t/31lob.t line 152. # got: undef # expected: '4' Errors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x000C68978], [0], [0], [0], [], [], [] sx�sx�sx� ��Errors in file : OCI-21500: internal error code, arguments: [kghufree_06], [0x000C68978], [0], [0], [0], [], [], [] j���sx�sx�sx� Dubious, test returned 1 (wstat 256, 0x100) Failed 4/12 subtests Test Summary Report --- t/31lob.t (Wstat: 256 Tests: 9 Failed: 1) Failed test: 9 Non-zero exit status: 1 Parse errors: Bad plan. You planned 12 tests but ran 9. Fi
Re: DBD::Oracle Release Candidate 1
On 11/02/11 18:43, John Scoles wrote:
Here is the latest and greatest DBD::Oracle for your programming pleasure.
You can find the Zip file here
http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip
This is a long overdue maintenance release that fixes a large number of bug and
issues which are detailed below in the Changes.
Don't worry there are some new goodies in this release namely I have added in 4
new
server side tracing/debugging attributes
ora_driver_name
For 11g and later you can now set the name of the driver layer using OCI.
PERL, PERL5, ApachePerl so on. Names starting with "ORA" are reserved. You
can enter up to 8 characters. If none is enter then this will default to
DBDO where is the current version number. This value can be
retrieved on the server side using V$SESSION_CONNECT_INFO or
GV$SESSION_CONNECT_INFO
ora_client_info
When passed in on the connection attributes it can specify any info you want
onto the session up t0 64 bytes. This value can be
retrieved on the server side using V$SESSION view.
ora_client_identifier
When passed in on the connection attributes it specifies the user identifier
in the session handle. Most useful for web app as it can pass in the session
user name which might be different than the connection user name. Can be up
to 64 bytes long do not to include the password for security reasons and the
first character of the identifier should not be ':'. This value can be
retrieved on the server side using V$SESSION view.
ora_action
You can set this value to anything you want up to 32byes.This value can be
retrieved on the server side using V$SESSION view.
We have also added in the connection attribute
ora_connect_with_default_signals
Whit this attribute you can localize the $SIG{} so this should solve the
problems with $SIG{} events that sometimes occur when using DBD::Oracle
Finally I would like to thank Martin Evans for volunteering to be another
co-maintainer of DBD::Oracle
Cheers
John Scoles
Changes
Added connection attribute 'ora_connect_with_default_signals' that will
localize Perl's $SIG{INT} handler from Brian Phillips and T. Bunce
Fix in execute_array to stop possible endless loop when using a fetch sub by
Martin J. Evans
Adapted Martin J. Evans' ODBC 70execute_array.t into t/26exe_array.t by John
Scoles
Fix for execute_array to bring it up to spec. by Martin J. Evans and John Scoles
Marked ProC, Oraperl.pm, ora_explain.pl, ora_context, ora_use_proc_connection
and ora_parse_lang as deprecated to be removed in 1.29
Added in 4 new server side debug/trace attributes, ora_driver_name,
ora_client_info, ora_session_user and ora_action on the connection handle from
John Scoles
Cleaned up the pod a little by John Scoles
Fix for function name length, Some function names are over 31char long which
may cause problems for some OS/Compilers (VMS IA64 box.) from Jakob Snoer
Fix for OCIPing in case where a 10 client tries to ping a <10 DB from Tim
Oertel
Fix for DBD-Oracle stored proc with array bug where second call array size is
unchanged from Tim Oertel
Fix for rt.cpan.org Ticket #=63332: Spelling error in POD from jonasbn
Fix for rt.cpan.org Ticket #=62152: t/28array_bind.t and t/31lob.t may call
plan() twice and others do not fail on not connect from John Scoles
Fix for rt.cpan.org Ticket #=61511 ORA-00942 when inserting into a table with a
LOB column over a synonym on HP-UX from Kris Lemaire
Fix for rt.cpan.org Ticket #=42842 Test 31lob fails with 64-bit Instant Client
by John Scoles
Fix for support for objects on big endian platforms from Charles Jardine, John
R Pierce
Fix for rt.cpan.org Ticket #=61225 Windows install (Stawberry Perl) fails on
long path names from David Tulloh
Fix for rt.cpan.org Ticket #=rt64524 Memory Leak when Oracle connection fails
by Martin J. Evans
Added all the missing ora_drcp values to dbh private_attribute_info by Martin
J. Evans
Removed a load of attributes from sth private_attribute_info which are not
handle attributes but attributes to bind_param/prepare by Martin J. Evans
Fix for rt.cpan.org Ticket #=64244 - don't bail out, skip tests when we
cannot connect by Martin J. Evans and John Scoles
Added DBI to PREREQ_PM in Makefile.PL by Martin J. Evans
Added build_requires in Makefile.PL by Martin J. Evans
Added workaround for ExtUtils::MakeMaker problems by Martin J. Evans
Added LICENSE to Makefile.PL by Martin J. Evans
Cheers John Scoles
Thanks John.
I haven't had a chance to play with this release candidate properly until today
- sorry.
On the platforms I've tested on so far (a few Linuxes) I am getting 100% test
success.
I will upgrade our test system to this RC later to see if it finds any problems.
The only problems I've found so far:
o the META.yml has not been generated properly (e.g., it is missing
build_required, configure_requires etc
o the version is still 1.27 instead of 1.28 - perhaps you intended that.
Martin
--
Martin J. Ev
Re: DBD::Oracle - credentials
On Fri, Jan 14, 2011 at 04:45:52PM +0100, H.Merijn Brand wrote: > > Yes, the *DBD::Oracle* README. I know, I found it there, but I was more > looking for guides from DBI. Does DBI document that DBU_USER/DBI_PASS > would somehow overrule other (default) settings? DBI_USER and DBI_PASS are applied as defaults in DBI->connect() so, if set, they'll be applied before the driver gets a chance to consider what to do. It's the $drh->default_user() method that looks up the env vars. That method isn't documented, which is a bug in itself. > I think the DBD::Oracle README does exactly what it said. So it is not > wrong. Agreed. There may be room for practical improvements if there are clear problems with the current behavior. Tim.
Re: DBD::Oracle - credentials
On Fri, 14 Jan 2011 15:21:39 +, "Martin J. Evans" wrote: > On 14/01/11 15:01, H.Merijn Brand wrote: > > On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans" > > wrote: > > > >> On 14/01/11 14:30, H.Merijn Brand wrote: > >>> Maybe this is a feature request, but if I have > >>> > >>> ORACLE_USERID=john/sekrit > >>> DBI_USER=pablo > >>> DBI_PASS=neruda > >>> > >>> I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* > >>> the ORACLE_USERID. Anyone can come up with a good reason why this os > >>> not happening at the moment? > >>> > >>> How do other DBD's set precedence if environment variable are allowed > >>> for login credentials? > >>> > >> > >> Just a minor point (not saying it stops the discussion) but I don't > >> think ORACLE_USERID is something DBD::Oracle defines (other than in > >> test code in t/*). So is your point to do with running tests in t/* or > >> in general? > > > > I ran into this in the test suite indeed. Your findings below just > > confirm my expectation :) > > > > I posted it here because I saw no generic docs about this > > It is in the README. Yes, the *DBD::Oracle* README. I know, I found it there, but I was more looking for guides from DBI. Does DBI document that DBU_USER/DBI_PASS would somehow overrule other (default) settings? I think the DBD::Oracle README does exactly what it said. So it is not wrong. > The supplied tests will connect to the database using the value of the > ORACLE_USERID environment variable to supply the username/password. > > Don't know why it cannot fall back on DBI_USER/DBI_PASS. > > >> $ export ORACLE_USERID=wrong/wrong > >> $ export DBI_USER=real_user > >> $ export DBI_PASS=valid_password > >> $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' > >> $ perl -le 'use DBI; my $h = DBI->connect();' > >> > >> works for me. i.e., ORACLE_USERID contains invalid username/password > >> and DBI_USER/DBI_PASS contain valid username/password and it connects > >> fine. > >> > >> Perhaps I misunderstood you Merijn. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle - credentials
On 14/01/2011 10:21 AM, Martin J. Evans wrote: On 14/01/11 15:01, H.Merijn Brand wrote: On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans" wrote: On 14/01/11 14:30, H.Merijn Brand wrote: Maybe this is a feature request, but if I have ORACLE_USERID=john/sekrit DBI_USER=pablo DBI_PASS=neruda I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* the ORACLE_USERID. Anyone can come up with a good reason why this os not happening at the moment? How do other DBD's set precedence if environment variable are allowed for login credentials? Just a minor point (not saying it stops the discussion) but I don't think ORACLE_USERID is something DBD::Oracle defines (other than in test code in t/*). So is your point to do with running tests in t/* or in general? I ran into this in the test suite indeed. Your findings below just confirm my expectation :) I posted it here because I saw no generic docs about this It is in the README. The supplied tests will connect to the database using the value of the ORACLE_USERID environment variable to supply the username/password. Don't know why it cannot fall back on DBI_USER/DBI_PASS. $ export ORACLE_USERID=wrong/wrong $ export DBI_USER=real_user $ export DBI_PASS=valid_password $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' $ perl -le 'use DBI; my $h = DBI->connect();' works for me. i.e., ORACLE_USERID contains invalid username/password and DBI_USER/DBI_PASS contain valid username/password and it connects fine. Perhaps I misunderstood you Merijn. Martin Martin Why not. Seems like a good Idea and easy to implement I guess we are just carrying on an old tradition nothing says we have to use ORACLE_USERID which is a little out dated. Time to update the POD and a tests I guess. Might be best for 1.29 as 1.28 is rather full right now. Cheers John
Re: DBD::Oracle - credentials
On 14/01/11 15:01, H.Merijn Brand wrote: > On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans" > wrote: > >> On 14/01/11 14:30, H.Merijn Brand wrote: >>> Maybe this is a feature request, but if I have >>> >>> ORACLE_USERID=john/sekrit >>> DBI_USER=pablo >>> DBI_PASS=neruda >>> >>> I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* >>> the ORACLE_USERID. Anyone can come up with a good reason why this os >>> not happening at the moment? >>> >>> How do other DBD's set precedence if environment variable are allowed >>> for login credentials? >>> >> >> Just a minor point (not saying it stops the discussion) but I don't >> think ORACLE_USERID is something DBD::Oracle defines (other than in >> test code in t/*). So is your point to do with running tests in t/* or >> in general? > > I ran into this in the test suite indeed. Your findings below just > confirm my expectation :) > > I posted it here because I saw no generic docs about this It is in the README. The supplied tests will connect to the database using the value of the ORACLE_USERID environment variable to supply the username/password. Don't know why it cannot fall back on DBI_USER/DBI_PASS. >> $ export ORACLE_USERID=wrong/wrong >> $ export DBI_USER=real_user >> $ export DBI_PASS=valid_password >> $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' >> $ perl -le 'use DBI; my $h = DBI->connect();' >> >> works for me. i.e., ORACLE_USERID contains invalid username/password >> and DBI_USER/DBI_PASS contain valid username/password and it connects >> fine. >> >> Perhaps I misunderstood you Merijn. >> >> Martin > > Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Oracle - credentials
On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans" wrote: > On 14/01/11 14:30, H.Merijn Brand wrote: > > Maybe this is a feature request, but if I have > > > > ORACLE_USERID=john/sekrit > > DBI_USER=pablo > > DBI_PASS=neruda > > > > I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* > > the ORACLE_USERID. Anyone can come up with a good reason why this os > > not happening at the moment? > > > > How do other DBD's set precedence if environment variable are allowed > > for login credentials? > > > > Just a minor point (not saying it stops the discussion) but I don't > think ORACLE_USERID is something DBD::Oracle defines (other than in > test code in t/*). So is your point to do with running tests in t/* or > in general? I ran into this in the test suite indeed. Your findings below just confirm my expectation :) I posted it here because I saw no generic docs about this > $ export ORACLE_USERID=wrong/wrong > $ export DBI_USER=real_user > $ export DBI_PASS=valid_password > $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' > $ perl -le 'use DBI; my $h = DBI->connect();' > > works for me. i.e., ORACLE_USERID contains invalid username/password > and DBI_USER/DBI_PASS contain valid username/password and it connects > fine. > > Perhaps I misunderstood you Merijn. > > Martin -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle - credentials
On 14/01/11 14:30, H.Merijn Brand wrote: > Maybe this is a feature request, but if I have > > ORACLE_USERID=john/sekrit > DBI_USER=pablo > DBI_PASS=neruda > > I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* > the ORACLE_USERID. Anyone can come up with a good reason why this os > not happening at the moment? > > How do other DBD's set precedence if environment variable are allowed > for login credentials? > Just a minor point (not saying it stops the discussion) but I don't think ORACLE_USERID is something DBD::Oracle defines (other than in test code in t/*). So is your point to do with running tests in t/* or in general? $ export ORACLE_USERID=wrong/wrong $ export DBI_USER=real_user $ export DBI_PASS=valid_password $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' $ perl -le 'use DBI; my $h = DBI->connect();' works for me. i.e., ORACLE_USERID contains invalid username/password and DBI_USER/DBI_PASS contain valid username/password and it connects fine. Perhaps I misunderstood you Merijn. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Oracle - credentials
On 14/01/2011 9:30 AM, H.Merijn Brand wrote: Maybe this is a feature request, but if I have ORACLE_USERID=john/sekrit DBI_USER=pablo DBI_PASS=neruda I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* the ORACLE_USERID. Anyone can come up with a good reason why this os not happening at the moment? How do other DBD's set precedence if environment variable are allowed for login credentials? Funny the question never came up before. I guess we can have a look at it. I do not know about the other drivers?
Re: DBD-Oracle stored proc with array bug
Built from SVN, works in our test environment.
John Scoles wrote, on or about 12/18/2010 8:08 PM:
Ok I got it to work 100% with the test seems you gave a little too much SP
You will find it in trunk of DBD::Oracle
which is here
http://svn.perl.org/modules/dbd-oracle/trunk
Thanks again
Cheers
John Scoles
On Tue, Dec 14, 2010 at 10:39 AM, Tim Oertel mailto:t...@samasher.com>> wrote:
Hi,
We were recently trying to pass an array to a stored procedure.
It worked fine the first call, but subsequent calls were receiving
the wrong array size, and with old array entries.
After some investigation, it looks like once an array parameter
is used with a given size array, it ignores any future array length.
i.e.
@array_of_something = (1, 2, 3, 4, 5);
$sth->bind_param(1, \...@array_of_something, {
ora_type => ORA_NUMBER_TABLE,
ora_internal_type => SQLT_INT });
$sth->execute();
@array_of_something = (6, 7, 8);
$sth->bind_param(1, \...@array_of_something, {
ora_type => ORA_NUMBER_TABLE,
ora_internal_type => SQLT_INT });
$sth->execute();
...doesn't do what is expected. The stored proceedure
receives an array of (6, 7, 8, 4, 5), in the second execute().
In the process of debugging that, we grabbed newer versions of DBD::Oracle,
to check if a more recent version had a fix, and lacking that, creating
a patch against svn.
Turned out we ran into a second bug, our dev system has recent Oracle
libraries on it, but our db is Oracle 9.2, and (after investigation) it
looks like there is a known issue with Oracle 10.2 libs, doing a ping
against 9.2, which causes a listener crash (I think).
The fix for that was to revert to the server version check if the server
is too old.
So, I've attached a patch, plus a test case for the first problem.
The patch is a patch against svn, 14564. It was tested on a Linux
box, with 10.2.0.3 client libs and 9.2.0.8.0 server, also running on
Linux.
If I've screwed up formatting, or need to do this differently, let me
know, and I'll try to fix it. If the fixes are wrong, I'm all ears
on that too.
--
Tim Oertel |"Why should I be content to simply
VP Engineering | live in this world, when I, as a
Ashergroup, Inc. | human being, can CREATE it?!"
585-586-0020 | IM via google/XMPP: ma...@jabber.com
Re: DBD-Oracle stored proc with array bug
Ok I got it to work 100% with the test seems you gave a little too much SP
You will find it in trunk of DBD::Oracle
which is here
http://svn.perl.org/modules/dbd-oracle/trunk
Thanks again
Cheers
John Scoles
On Tue, Dec 14, 2010 at 10:39 AM, Tim Oertel wrote:
>
> Hi,
>
> We were recently trying to pass an array to a stored procedure.
> It worked fine the first call, but subsequent calls were receiving
> the wrong array size, and with old array entries.
>
> After some investigation, it looks like once an array parameter
> is used with a given size array, it ignores any future array length.
>
> i.e.
>
> @array_of_something = (1, 2, 3, 4, 5);
>
> $sth->bind_param(1, \...@array_of_something, {
> ora_type => ORA_NUMBER_TABLE,
> ora_internal_type => SQLT_INT });
> $sth->execute();
>
> @array_of_something = (6, 7, 8);
>
> $sth->bind_param(1, \...@array_of_something, {
> ora_type => ORA_NUMBER_TABLE,
> ora_internal_type => SQLT_INT });
> $sth->execute();
>
> ...doesn't do what is expected. The stored proceedure
> receives an array of (6, 7, 8, 4, 5), in the second execute().
>
>
> In the process of debugging that, we grabbed newer versions of DBD::Oracle,
> to check if a more recent version had a fix, and lacking that, creating
> a patch against svn.
>
> Turned out we ran into a second bug, our dev system has recent Oracle
> libraries on it, but our db is Oracle 9.2, and (after investigation) it
> looks like there is a known issue with Oracle 10.2 libs, doing a ping
> against 9.2, which causes a listener crash (I think).
>
> The fix for that was to revert to the server version check if the server
> is too old.
>
>
> So, I've attached a patch, plus a test case for the first problem.
> The patch is a patch against svn, 14564. It was tested on a Linux
> box, with 10.2.0.3 client libs and 9.2.0.8.0 server, also running on
> Linux.
>
>
> If I've screwed up formatting, or need to do this differently, let me
> know, and I'll try to fix it. If the fixes are wrong, I'm all ears
> on that too.
>
>
> --
> Tim Oertel |"Why should I be content to simply
> VP Engineering | live in this world, when I, as a
> Ashergroup, Inc. | human being, can CREATE it?!"
> 585-586-0020 | IM via google/XMPP: ma...@jabber.com
>
--
>From the Pythian family to yours, Happy Holidays and all the best in 2011!
Re: DBD::Oracle 1.26 new_tablename / synonyms issue
I have applied this patch to trunk you can find it here
http://svn.perl.org/modules/dbd-oracle/trunk
It will be part of Release 1.28 sometime before the end of the month.
Cheers
John Scoles
On Tue, Nov 16, 2010 at 10:28 AM, Jan Pazdziora wrote:
>
> Hello,
>
> The DBD::Oracle 1.26 code
>
>http://cpansearch.perl.org/src/TIMB/DBD-Oracle-1.26/oci8.c
>
> declares
>
>char new_tablename[100];
>
> in the if branch in init_lob_refetch, and then assigns
>
>tablename=new_tablename;
>
> and then uses the tablename outside of that if block. So the
> tablename pointer points to a random address on the stack.
>
> It causes problems described at
>
>http://rt.cpan.org/Public/Bug/Display.html?id=61511
>https://bugzilla.redhat.com/show_bug.cgi?id=548489
>
> Note that it's kinda related to
>
>http://rt.cpan.org/Public/Bug/Display.html?id=36069#txn-464638
>
> where it's said
>
>Used some of the code form the patch there was no need to
>create a char [100] outside the if statement though.
>
> I'd claim that it is actually necessary to declare it outside of
> that block because even if the name goes out of scope at the end
> of the block, the tablename pointer still points to it.
>
> Please apply
>
> --- oci8.c.orig 2010-11-16 16:26:42.459208675 +0100
> +++ oci8.c 2010-11-16 16:27:27.194207404 +0100
> @@ -4030,6 +4030,7 @@
>ub2 numcols = 0;
>imp_fbh_t *fbh;
>int unmatched_params;
> + char new_tablename[100];
>I32 i,j;
>char *p;
>lob_refetch_t *lr = NULL;
> @@ -4067,7 +4068,6 @@
>if (status == OCI_SUCCESS) { /* There is a synonym, get the schema
> */
>char *syn_schema=NULL;
>char syn_name[100];
> - char new_tablename[100];
>ub4 tn_len = 0, syn_schema_len = 0;
>
>strncpy(syn_name,tablename,strlen(tablename));
>
> to DBD::Oracle.
>
> Thank you,
>
> --
> Jan Pazdziora
>
--
>From the Pythian family to yours, Happy Holidays and all the best in 2011!
Re: DBD-Oracle stored proc with array bug
Okay, I'll keep my eyes on the list, at least until then. :)
John Scoles wrote, on or about 12/14/2010 12:43 PM:
Ok thanks for that.
At first glance this looks like it might fix another reported bug and it
is doing some work for me as I wanted to add in
OCIServerRelease_log for my own selfish reasons so thanks for that:)
It will be going into 1.28 as 1.27 is reserved for a PERL_POLLUTE release which
should be out soon
Cheers
John Scoles
On 14/12/2010 10:39 AM, Tim Oertel wrote:
Hi,
We were recently trying to pass an array to a stored procedure.
It worked fine the first call, but subsequent calls were receiving
the wrong array size, and with old array entries.
After some investigation, it looks like once an array parameter
is used with a given size array, it ignores any future array length.
i.e.
@array_of_something = (1, 2, 3, 4, 5);
$sth->bind_param(1, \...@array_of_something, {
ora_type => ORA_NUMBER_TABLE,
ora_internal_type => SQLT_INT });
$sth->execute();
@array_of_something = (6, 7, 8);
$sth->bind_param(1, \...@array_of_something, {
ora_type => ORA_NUMBER_TABLE,
ora_internal_type => SQLT_INT });
$sth->execute();
...doesn't do what is expected. The stored proceedure
receives an array of (6, 7, 8, 4, 5), in the second execute().
In the process of debugging that, we grabbed newer versions of
DBD::Oracle,
to check if a more recent version had a fix, and lacking that, creating
a patch against svn.
Turned out we ran into a second bug, our dev system has recent Oracle
libraries on it, but our db is Oracle 9.2, and (after investigation) it
looks like there is a known issue with Oracle 10.2 libs, doing a ping
against 9.2, which causes a listener crash (I think).
The fix for that was to revert to the server version check if the server
is too old.
So, I've attached a patch, plus a test case for the first problem.
The patch is a patch against svn, 14564. It was tested on a Linux
box, with 10.2.0.3 client libs and 9.2.0.8.0 server, also running on
Linux.
If I've screwed up formatting, or need to do this differently, let me
know, and I'll try to fix it. If the fixes are wrong, I'm all ears
on that too.
--
Tim Oertel |"Why should I be content to simply
VP Engineering | live in this world, when I, as a
Ashergroup, Inc. | human being, can CREATE it?!"
585-586-0020 | IM via google/XMPP: ma...@jabber.com
Re: DBD-Oracle stored proc with array bug
Ok thanks for that.
At first glance this looks like it might fix another reported bug and it
is doing some work for me as I wanted to add in
OCIServerRelease_log for my own selfish reasons so thanks for that:)
It will be going into 1.28 as 1.27 is reserved for a PERL_POLLUTE release which
should be out soon
Cheers
John Scoles
On 14/12/2010 10:39 AM, Tim Oertel wrote:
Hi,
We were recently trying to pass an array to a stored procedure.
It worked fine the first call, but subsequent calls were receiving
the wrong array size, and with old array entries.
After some investigation, it looks like once an array parameter
is used with a given size array, it ignores any future array length.
i.e.
@array_of_something = (1, 2, 3, 4, 5);
$sth->bind_param(1, \...@array_of_something, {
ora_type => ORA_NUMBER_TABLE,
ora_internal_type => SQLT_INT });
$sth->execute();
@array_of_something = (6, 7, 8);
$sth->bind_param(1, \...@array_of_something, {
ora_type => ORA_NUMBER_TABLE,
ora_internal_type => SQLT_INT });
$sth->execute();
...doesn't do what is expected. The stored proceedure
receives an array of (6, 7, 8, 4, 5), in the second execute().
In the process of debugging that, we grabbed newer versions of
DBD::Oracle,
to check if a more recent version had a fix, and lacking that, creating
a patch against svn.
Turned out we ran into a second bug, our dev system has recent Oracle
libraries on it, but our db is Oracle 9.2, and (after investigation) it
looks like there is a known issue with Oracle 10.2 libs, doing a ping
against 9.2, which causes a listener crash (I think).
The fix for that was to revert to the server version check if the server
is too old.
So, I've attached a patch, plus a test case for the first problem.
The patch is a patch against svn, 14564. It was tested on a Linux
box, with 10.2.0.3 client libs and 9.2.0.8.0 server, also running on
Linux.
If I've screwed up formatting, or need to do this differently, let me
know, and I'll try to fix it. If the fixes are wrong, I'm all ears
on that too.
Re: DBD::Oracle 1.26 does not install with CentOS/RHEL 5.5 and OIC 11.2
On 06/12/10 20:32, Alexander Farber wrote: > Hello, > > I have installed the following packages: > > oracle-instantclient11.2-basic-11.2.0.2.0.x86_64.rpm > oracle-instantclient11.2-devel-11.2.0.2.0.x86_64.rpm > oracle-instantclient11.2-sqlplus-11.2.0.2.0.x86_64.rpm > > on my CentOS 5.5 Linux / 64 bit with perl 5.8.8 > and have set the following env. variables: > > export TNS_ADMIN=/etc > export ORACLE_HOME=/usr/lib/oracle/11.2 > export LD_LIBRARY_PATH=$ORACLE_HOME/client64/lib > PATH=$PATH:$HOME/bin:/sbin:$ORACLE_HOME/client64/bin > > After that I'm able to access the remote Oracle database > through sqlplus shell and PHP (with: extension=oci8.so) > > Installing DBD::Oracle through CPAN shell fails however > (installing other Perl modules previously has worked well): > > # sudo -E perl -MCPAN -e shell > > cpan shell -- CPAN exploration and modules installation (v1.9402) > Enter 'h' for help. > > cpan[1]> install DBD::Oracle > CPAN: Storable loaded ok (v2.15) > Going to read '/home/afarber/.cpan/Metadata' > Database was generated on Mon, 06 Dec 2010 04:30:56 GMT > Running install for module 'DBD::Oracle' > Running make for T/TI/TIMB/DBD-Oracle-1.26.tar.gz > CPAN: Digest::SHA loaded ok (v5.48) > CPAN: Compress::Zlib loaded ok (v2.03) > Checksum for > /home/afarber/.cpan/sources/authors/id/T/TI/TIMB/DBD-Oracle-1.26.tar.gz > ok > Scanning cache /home/afarber/.cpan/build for sizes > .---DONE > CPAN: File::Temp loaded ok (v0.22) > CPAN: YAML loaded ok (v0.72) > > CPAN.pm: Going to build T/TI/TIMB/DBD-Oracle-1.26.tar.gz > > Using DBI 1.52 (for perl 5.008008 on x86_64-linux-thread-multi) > installed in > /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/ > > Configuring DBD::Oracle for perl 5.008008 on linux (x86_64-linux-thread-multi) > > Remember to actually *READ* the README file! Especially if you have > any problems. > > The ORACLE_HOME environment variable value (/usr/lib/oracle/11.2) is > not valid. Is /usr/lib/oracle/11.2 where you really unzipped/installed the instant client? because DBD::Oracle does not recognise this path as containing the instant client. > It must be set to hold the path to an Oracle installation directory > on this machine (or a machine with a compatible architecture). > For an Instant Client install, the directory should include an sdk > subdirectory. > See the appropriate README file for your OS for more information. > ABORTED! > Warning: No success on command[/usr/bin/perl Makefile.PL] > TIMB/DBD-Oracle-1.26.tar.gz > /usr/bin/perl Makefile.PL -- NOT OK > Running make test > Make had some problems, won't test > Running make install > Make had some problems, won't install > Failed during this command: > TIMB/DBD-Oracle-1.26.tar.gz : writemakefile NO > '/usr/bin/perl Makefile.PL' returned status 512 > > > The "sdk" subdir mentioned above doesn't really exist in the rpm: > > # rpm -ql oracle-instantclient11.2-devel | grep -i sdk > # > > Thank you > Alex I don't use rpms to install instant client and it works fine. You need the sdk. You could try downloading the zip versions and unzipping them somewhere and point LD_LIBRARY_PATH to the unzip dir - I don't think you need to set ORACLE_HOME with DBD::Oracle and instant client and in some rare cases it actually breaks the install. > # perl -V > Summary of my perl5 (revision 5 version 8 subversion 8) configuration: > Platform: > osname=linux, osvers=2.6.18-53.el5, archname=x86_64-linux-thread-multi > uname='linux builder10.centos.org 2.6.18-53.el5 #1 smp mon nov 12 > 02:14:55 est 2007 x86_64 x86_64 x86_64 gnulinux ' > config_args='-des -Doptimize=-O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -Dversion=5.8.8 > -Dmyhostname=localhost -dperladmin=r...@localhost -Dcc=gcc -Dcf_by=Red > Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Dlibpth=/usr/local/lib64 > /lib64 /usr/lib64 -Dprivlib=/usr/lib/perl5/5.8.8 > -Dsitelib=/usr/lib/perl5/site_perl/5.8.8 > -Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.8 > -Darchlib=/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi > -Dsitearch=/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi > -Dvendorarch=/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi > -Darchname=x86_64-linux-thread-multi -Dvendorprefix=/usr > -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads > -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm > -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n > -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr > -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto > -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto > -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 > -Dscriptdir=/usr/bin' > hint=recommended, usepos
Re: DBD::Oracle DRCP_1.25
On Jul 6, 7:36 am, sco...@pythian.com (John Scoles) wrote: > > Gee didn't know anyone else was even interested in DRCP. good to see > there is some interest I know this post is more than a month old, but I am very excited about this. I just found that DBD::Oracle 1.2.5 was nearly ready. I have been looking forward to DRCP support for awhile now. We have Oracle 11.1 and 11.2 running on HP-UX with Perl 5.10, and we have a production app that makes thousands of connections a day using Perl (and a web interface in PHP that does the same thing, but it has pooling there.) Anyway, I am looking forward to getting this onto our test system, and trying it out. Thanks for all your hard work. -- Cliff
Re: DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes
On Fri, 06 Aug 2010 09:56:36 +0100, Charles Jardine
wrote:
> On 05/08/10 12:49, H.Merijn Brand wrote:
>
> Snip
>
> > $dbh->do (qq;
> > create global temporary table t_foo (
> > h_key blob,
> > h_value blob
> > );
> > );
> >
> > my $sth = $dbh->prepare ("select h_value from t_foo where h_key = ?");
> > $ perl test.pl
> > DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes: expected
> > - got BLOB (DBD ERROR: error possibly near <*> indicator at char 32 in
> > 'select h_value from t_foo where <*>h_key = :p1') [for Statement "select
> > h_value from t_foo where h_key = ?"] at test.pl line 23.
>
> This is nothing to do with perl. You get this message from Oracle if you
> attempt to compare a blob with anything, including itself.
How ultimately useless. Yet another reason to hate Oracle.
Thanks for the heads-up though.
> Here is a simple demonstration using SQLPlus.
>
> Connected to:
> Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
> SQL> create table t_foo (h_key blob);
> Table created.
> SQL> select h_key from t_foo where h_key = h_key;
> select h_key from t_foo where h_key = h_key
>*
> ERROR at line 1:
> ORA-00932: inconsistent datatypes: expected - got BLOB
>
> It is a bad error message, but the rule is clear. This is
> from the section on Comparison Conditions in the Oracle 10.2
> SQL Reference Manual
>
> > Large objects (LOBs) are not supported in comparison conditions.
> > However, you can use PL/SQL programs for comparisons on CLOB data.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes
On 05/08/10 12:49, H.Merijn Brand wrote:
Snip
> $dbh->do (qq;
> create global temporary table t_foo (
> h_key blob,
> h_value blob
> );
> );
>
> my $sth = $dbh->prepare ("select h_value from t_foo where h_key = ?");
> $ perl test.pl
> DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes: expected -
> got BLOB (DBD ERROR: error possibly near <*> indicator at char 32 in 'select
> h_value from t_foo where <*>h_key = :p1') [for Statement "select h_value from
> t_foo where h_key = ?"] at test.pl line 23.
This is nothing to do with perl. You get this message from Oracle if you
attempt to compare a blob with anything, including itself. Here is a
simple demonstration using SQLPlus.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
SQL> create table t_foo (h_key blob);
Table created.
SQL> select h_key from t_foo where h_key = h_key;
select h_key from t_foo where h_key = h_key
*
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected - got BLOB
It is a bad error message, but the rule is clear. This is
from the section on Comparison Conditions in the Oracle 10.2
SQL Reference Manual
> Large objects (LOBs) are not supported in comparison conditions.
> However, you can use PL/SQL programs for comparisons on CLOB data.
--
Charles Jardine - Computing Service, University of Cambridge
c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
Re: DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes
On Thu, 5 Aug 2010 13:49:57 +0200, "H.Merijn Brand"
wrote:
> my $sth = $dbh->prepare ("select h_value from t_foo where h_key = ?");
> $ perl test.pl
> DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes: expected -
> got BLOB (DBD ERROR: error possibly near <*> indicator at char 32 in 'select
> h_value from t_foo where <*>h_key = :p1') [for Statement "select h_value from
> t_foo where h_key = ?"] at test.pl line 23.
> DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes: expected -
> got BLOB (DBD ERROR: error possibly near <*> indicator at char 32 in 'select
> h_value from t_foo where <*>h_key = :p1') [for Statement "select h_value from
> t_foo where h_key = ?"] at test.pl line 23.
> Issuing rollback() due to DESTROY without explicit disconnect() of
> DBD::Oracle::db handle at test.pl line 23.
With 1.25rc2
$ perl /tmp/test.pl
DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes: expected -
got BLOB (DBD ERROR: error possibly near <*> indicator at char 32 in 'select
h_value from t_foo where <*>h_key = :p1') [for Statement "select h_value from
t_foo where h_key = ?"] at /tmp/test.pl line 23.
DBD::Oracle::db prepare failed: ORA-00932: inconsistent datatypes: expected -
got BLOB (DBD ERROR: error possibly near <*> indicator at char 32 in 'select
h_value from t_foo where <*>h_key = :p1') [for Statement "select h_value from
t_foo where h_key = ?"] at /tmp/test.pl line 23.
Issuing rollback() due to DESTROY without explicit disconnect() of
DBD::Oracle::db handle at /tmp/test.pl line 23.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle DRCP_1.25
On 9.07.2010 00:41, John Scoles wrote:
Hi Luben
I have incorporated your patch into the DRCP branch and I have also merged
that branch back into trunk for any testing that you will be doing I would
try it with the Trunk which you can find here
http://svn.perl.org/modules/dbd-oracle/trunk
I went with the ORA_DRCP_* for the attribute names rather than POOL.
as well I made ORA_DRCP_CLASS an optional value. Some users my not want to
use it.
Thanks again
John Scoles
Nice, this are better names. Here comes a patch to suppress warnings in
scripts that are invoked with "perl -w"
luben
Index: Oracle.pm
===
--- Oracle.pm (revision 14240)
+++ Oracle.pm (working copy)
@@ -189,10 +189,10 @@
} split /\s*;\s*/, $dbname;
my %dbname = ( PROTOCOL => 'tcp', @dbname );
-if ($dbname{SERVER} eq "POOLED") {
- $attr->{ora_drcp}=1;
-
+if ((exists $dbname{SERVER}) and ($dbname{SERVER} eq "POOLED")) {
+$attr->{ora_drcp}=1;
}
+
# extract main attributes for connect_data portion
my @connect_data_attr = qw(SID INSTANCE_NAME SERVER SERVICE_NAME );
my %connect_data = map { ($_ => delete $dbname{$_}) }
Re: DBD::Oracle DRCP_1.25
Hi Luben I have incorporated your patch into the DRCP branch and I have also merged that branch back into trunk for any testing that you will be doing I would try it with the Trunk which you can find here http://svn.perl.org/modules/dbd-oracle/trunk I went with the ORA_DRCP_* for the attribute names rather than POOL. as well I made ORA_DRCP_CLASS an optional value. Some users my not want to use it. Thanks again John Scoles On Wed, Jul 7, 2010 at 4:34 PM, luben karavelov wrote: > As I have promissed, here comes the documentation patch. I am not native > speeker, so may be it will need an edit. > > Also, I have added processing of environment valiables ORA_POOL_CLASS, > ORA_POOL_MIN, ORA_POOL_MAX, ORA_POOL_INCR if there is ORA_DRCP env set. > > Best regards > luben > -- New! Learn why & how to love your data with Pythian's new webinar series. Topics, details & register: http://www.pythian.com/webinars
Re: DBD::Oracle DRCP_1.25
As I have promissed, here comes the documentation patch. I am not native
speeker, so may be it will need an edit.
Also, I have added processing of environment valiables ORA_POOL_CLASS,
ORA_POOL_MIN, ORA_POOL_MAX, ORA_POOL_INCR if there is ORA_DRCP env set.
Best regards
luben
Index: Oracle.pm
===
--- Oracle.pm (revision 14227)
+++ Oracle.pm (working copy)
@@ -227,14 +227,26 @@
# create a 'blank' dbh
$user = '' if not defined $user;
-(my $user_only = $user) =~ s:/.*::;
-
-if (substr($dbname,-7,7) eq ':POOLED'){
- $dbname=substr($dbname,0,-7);
- $attr->{ora_drcp} = 1;
+(my $user_only = $user) =~ s:/.*::;
+
+if (substr($dbname,-7,7) eq ':POOLED'){
+ $dbname=substr($dbname,0,-7);
+ $attr->{ora_drcp} = 1;
+}
+elsif ($ENV{ORA_DRCP}){
+$attr->{ora_drcp} = 1;
+if (exists $ENV{ORA_POOL_CLASS}) {
+$attr->{ora_pool_class} = $ENV{ORA_POOL_CLASS}
}
-elsif ($ENV{ORA_DRCP}){
- $attr->{ora_drcp} = 1;
+if (exists $ENV{ORA_POOL_MIN}) {
+$attr->{ora_pool_min} = $ENV{ORA_POOL_MIN}
+}
+if (exists $ENV{ORA_POOL_MAX}) {
+$attr->{ora_pool_max} = $ENV{ORA_POOL_MAX}
+}
+if (exists $ENV{ORA_POOL_INCR}) {
+$attr->{ora_pool_incr} = $ENV{ORA_POOL_INCR}
+}
}
my ($dbh, $dbh_inner) = DBI::_new_dbh($drh, {
@@ -1346,7 +1358,7 @@
$dbh = DBI->connect('dbi:Oracle:','usern...@db:POOLED','password')
- $dbh = DBI->connect('dbi:Oracle:DB','username','password',{ora_drcp=>1})
+ $dbh = DBI->connect('dbi:Oracle:DB','username','password',{ora_drcp=>1,
ora_pool_class=>'my_app', ora_pool_min=>10})
$dbh =
DBI->connect('dbi:Oracle:host=foobar;sid=ORCL;port=1521;SERVER=POOLED',
'scott/tiger', '')
@@ -1354,7 +1366,7 @@
(ADDRESS=(PROTOCOL=TCP)(HOST= foobar)(PORT=1521))
(CONNECT_DATA=(SID=ORCL)(SERVER=POOLED)))}, "")
- if ORA_DRCP environemt var is set the just this
+ if ORA_DRCP and ORA_POOL_CLASS environemt var are set you could use just this
$dbh = DBI->connect('dbi:Oracle:DB','username','password')
@@ -1530,13 +1542,60 @@
=item ora_drcp
-If you have an 11.2 or greater database your can utilize the the DRCP by
setting
-this attribute to 1 at connect time.
+If you have an 11.2 or greater database your can utilize the the DRCP
+(Database Resident Connection Pooling) by setting this attribute to 1
+at connect time.
For convenience I have added support for a 'ORA_DRCP'
environment variable that you can use at the OS level to set this
value. If used it will take the value at the connect stage.
+=item ora_pool_class
+
+If you use DRCP, you could set CONNECTION_CLASS at connection time.
+
+The connections are pooled based on unique SID/USERNAME/CONNECTION_CLASS.
+If you do not set the class attribute the connections will be pooled only
+within the boundaries of the process, becoming equivalent to a plain
+client-side session pooling application.
+
+For convenience I have added support for a 'ORA_POOL_CLASS'
+environment variable that you can use at the OS level to set this
+value. It will be used only if you use 'ORA_DRCP' environment variable.
+If used it will take the value at the connect stage.
+
+=item ora_pool_min
+
+If you use DRCP, you could set initial servers in the pool that will get
+started. Default value is 4 as per DBMS_CONNECTION_POOL default.
+
+For convenience I have added support for a 'ORA_POOL_MIN'
+environment variable that you can use at the OS level to set this
+value. It will be used only if you use 'ORA_DRCP' environment variable.
+If used it will take the value at the connect stage.
+
+
+=item ora_pool_max
+
+If you use DRCP, you could set maximum servers in the pool. Default value
+is 40 as per DBMS_CONNECTION_POOL default.
+
+For convenience I have added support for a 'ORA_POOL_MAX'
+environment variable that you can use at the OS level to set this
+value. It will be used only if you use 'ORA_DRCP' environment variable.
+If used it will take the value at the connect stage.
+
+=item ora_pool_incr
+
+If you use DRCP, you could set how much new servers will get started if all
+servers in the pool are busy. Default value is 2 as per DBMS_CONNECTION_POOL
+default.
+
+For convenience I have added support for a 'ORA_POOL_INCR'
+environment variable that you can use at the OS level to set this
+value. It will be used only if you use 'ORA_DRCP' environment variable.
+If used it will take the value at the connect stage.
+
=item ora_session_mode
The ora_session_mode attribute can be used to connect with SYSDBA
Re: DBD::Oracle DRCP_1.25
On 6.07.2010 14:36, John Scoles wrote:
luben wrote:
Gee didn't know anyone else was even interested in DRCP. good to see
there is some interest
Just to let you know that branch is in the very Beta stages so expect a
few things to be missing
Yes, I know it is in beta. I was just intereseted.
Ok would like to see the code for that/
I have attached the patch against DRCP branch
Finally, if this work is accepted I will add proper documentation for
the new attributes.
That would save me some trouble.
Now I have a little favour to ask of you. Seems I am getting a problem
with 31lob.t test 8 the sql "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;";
does not return the correct length when used with DRCP
If you have half a moment and can take a look at that one that would be
great.
Tomorrow I will send a patch for the documentation.
I am not experienced with perl driver hacking but I will take a look on
the failing LOB test and try to figure what is going on.
Best regards
luben
Index: dbdimp.c
===
--- dbdimp.c(revision 14227)
+++ dbdimp.c(working copy)
@@ -388,8 +388,21 @@
#ifdef ORA_OCI_112
/*check to see if the user is connecting with DRCP */
+STRLEN svp_len;
if (DBD_ATTRIB_TRUE(attr,"ora_drcp",8,svp))
imp_dbh->using_drcp = 1;
+if ((svp=DBD_ATTRIB_GET_SVP(attr, "ora_pool_class", 14)) && SvOK(*svp)) {
+if (!SvPOK(*svp))
+croak("ora_pool_class is not a string");
+imp_dbh->pool_class = (text *) SvPV (*svp, svp_len );
+imp_dbh->pool_classl= (ub4) svp_len;
+}
+if (DBD_ATTRIB_TRUE(attr,"ora_pool_min",12,svp))
+DBD_ATTRIB_GET_IV( attr, "ora_pool_min", 12, svp, imp_dbh->pool_min);
+if (DBD_ATTRIB_TRUE(attr,"ora_pool_max",12,svp))
+DBD_ATTRIB_GET_IV( attr, "ora_pool_max", 12, svp, imp_dbh->pool_max);
+if (DBD_ATTRIB_TRUE(attr,"ora_pool_incr",13,svp))
+DBD_ATTRIB_GET_IV( attr, "ora_pool_incr", 13, svp,
imp_dbh->pool_incr);
#endif
/* check to see if DBD_verbose or ora_verbose is set*/
if (DBD_ATTRIB_TRUE(attr,"dbd_verbose",11,svp))
@@ -793,6 +806,10 @@
if (imp_dbh->using_drcp) { /* connect uisng a
DRCP */
ub4 purity = OCI_ATTR_PURITY_SELF;
+/* some pool default values */
+if (!imp_dbh->pool_min ) imp_dbh->pool_min=4;
+if (!imp_dbh->pool_max ) imp_dbh->pool_max=40;
+if (!imp_dbh->pool_incr) imp_dbh->pool_incr=2;
OCIHandleAlloc_ok(imp_dbh->envhp,
&imp_dbh->poolhp, OCI_HTYPE_SPOOL, status);
@@ -801,14 +818,14 @@
imp_dbh->poolhp,
(OraText **)
&imp_dbh->pool_name,
(ub4 *)
&imp_dbh->pool_namel,
- dbname,
+ (OraText *) dbname,
strlen(dbname),
- 10,
- 100,
- 4,
- uid,
+ imp_dbh->pool_min,
+ imp_dbh->pool_max,
+ imp_dbh->pool_incr,
+ (OraText *) uid,
strlen(uid),
- pwd,
+ (OraText *) pwd,
strlen(pwd),
status);
@@ -827,6 +844,10 @@
OCIAttrSet_log_stat(imp_dbh->authp,
(ub4) OCI_HTYPE_AUTHINFO,
&purity, (ub4)
0,(ub4) OCI_ATTR_PURITY, imp_dbh->errhp, status);
+ OCIAttrSet_log_stat(imp_dbh->authp,
(ub4) OCI_HTYPE_AUTHINFO,
+ (OraText *)
imp_dbh->pool_class, (ub4) imp_dbh->pool_classl,
+(ub4) OCI_ATTR_CONNECTION_CLASS,
imp_dbh->errhp, status);
+
cred_type = ora_parse_uid(imp_dbh,
&uid, &pwd);
OCISessionGet_log_stat(imp_dbh->envhp,
imp_dbh->errhp, &imp_dbh->svchp, imp_dbh->authp,
@@ -1103,6 +1124,7 @@
{
dTHX;
STRLEN kl;
+STRLEN vl;
char *key = SvPV(
Re: DBD::Oracle DRCP_1.25
luben wrote: Gee didn't know anyone else was even interested in DRCP. good to see there is some interest Just to let you know that branch is in the very Beta stages so expect a few things to be missing Hello, I have noticed and installed DRCP_1.25 branch from DBD::Oracle repository. It seems to work fine but it's missing some essential functionality in order to make it usefull. So I have made local modifications (some of them are not essential) and all seems to work fine here. What I have done: 1. essential - added ora_pool_class connection attribute that sets OCI_ATTR_CONNECTION_CLASS on the obtained connection. It is essential because without setting this attribute the pooled sessions are not shared between processes. From oracle documentation: > If no connection class is specified, the OCISessionPool’s name is implicitly used > as the connection class by all the requests using that OCISessionPool, resulting in > sharing only within a session pool, becoming equivalent to a plain client-side > session pooling application. Ok would like to see the code for that/ 2.non-essential - Added ora_pool_min, ora_pool_max, ora_pool_incr connections attributes that are used to set corresponding values for OCISessionPoolCreate. - Set default values for the above parameters to follow default values of DBMS_CONNECTION_POOL package (principle of least surprise) I have those stubbed in for now as I was deliberately using small min and max for testing and will check them in soon I most likely. Part of the plan was to use the default values. I have some questions: 1. Do you have suggestions for different names of attributes? I was considering ora_drcp_class etc. but I am not sure what will be the best. ora_drcp_conn_class would be better so as not to get it confused with any other thing that might be a 'class' of some sort 2. If my work is interesting for the further development of DBD::Oracle, whom I should send a patch? Just post it here on this thread or on DBI-users just make sure it is patched from the DRCP branch. Finally, if this work is accepted I will add proper documentation for the new attributes. That would save me some trouble. Now I have a little favour to ask of you. Seems I am getting a problem with 31lob.t test 8 the sql "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;"; does not return the correct length when used with DRCP If you have half a moment and can take a look at that one that would be great. Cheers John Scoles Best regards luben karavelov
Re: DBD::Oracle 11gr2 & ORA-38909
On Fri, 2010-06-04 at 16:42 -0400, John Scoles wrote:
> Had a quick look at it today give it a try agian but this time make
> sure you have autocommit off
>
>
> AutoCommit=>1
This turns it on, so you want it on or off?
>
> on the connection method
>
> cheers
>
> On Fri, May 21, 2010 at 11:20 AM, John Scoles
> wrote:
> Ok I guess it is back to square 1 on this.
>
> Unfortunetly no time to look at it today
>
> Will write up a small test script and see if my patch actually
> does anything
>
> You may hear from me in a few days
>
> Cheers
> John
>
>
>
>
> Scott T. Hildreth wrote:
> On Fri, 2010-05-21 at 09:23 +0100, Martin Evans wrote:
>
> John Scoles wrote:
>
> Ok I have patched up a solution I
> think will work across the board and
> you
> can find it here
>
>
> http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
>
> here are the details
>
> ora_oci_batch
>
> For 11g users you may encounter an
> error while using the execute_array in
> that it does not
> return a full list of tuples. This
> seems to be a result in that a
> statement
> can only
> have 'LOG ERRORS' or 'SAVE
> EXCEPTIONS'set, By setting this flag
> to a value
> should stop this
> problem error.
>
> For convenience I have added support
> for a 'ORA_DBD_OCI_BATCH'
> environment variable that you can use
> at the OS level to set this
> value. It can also be set as an
> attribute on both the Connect and
> Prepare.
>
> Unfortunately I can't test it (do not
> have an 11g box yet) so It will stay
> in the above branch until it is tested
> hopefully by you Scott
>
> Cheers
> John Scoles
>
> --
> See Pythian's Alex Gorbachev,
> co-author of "Expert Oracle Practices"
> at NoCOUG Spring Conference May 20th.
> Details, interview & book chapter in
> the May NoCOUG Journal:
> http://bit.ly/alexnocoug
>
>
> I'm not sure why I seem to have ignored your
> mail but I just noticed it
> again - sorry for the delay.
>
> I checked out the branch you mentioned and
>
> export ORA_DBD_OCI_BATCH=1
>
> but 26exe_array still seems to fail for me:
>
>
> Sorry John, I meant to test earlier but its been a
> busy week.
>
> Fails for me as well.
>
> DB<7> x $dbh->{'ora_oci_batch'}
> 0 1
> DB<8> n
> main::(../tst_exec_ary.pl:13): my $sth =
> $dbh->prepare("Insert into TestArray Values(?, ?, ?)
> LOG ERRORS INTO ERR_TESTARRAY");
> DB<8> n
> main::(../tst_exec_ary.pl:15):
> $sth->bind_param_array(1, [ qw(One Uno Il oNe) ]);
> DB<8> n
> main::(../tst_exec_ary.pl:16):
> $sth->bind_param_array(2, [ 2, 22, 0, 222 ]);
> DB<8> n
> main::(../tst_exec_ary.pl:17):
> $sth->bind_param_array(3, [ qw(20070101 20080101
>
Re: DBD::Oracle 11gr2 & ORA-38909
Had a quick look at it today give it a try agian but this time make sure you
have autocommit off
AutoCommit=>1
on the connection method
cheers
On Fri, May 21, 2010 at 11:20 AM, John Scoles wrote:
> Ok I guess it is back to square 1 on this.
>
> Unfortunetly no time to look at it today
>
> Will write up a small test script and see if my patch actually does
> anything
>
> You may hear from me in a few days
>
> Cheers
> John
>
>
>
> Scott T. Hildreth wrote:
>
>> On Fri, 2010-05-21 at 09:23 +0100, Martin Evans wrote:
>>
>>
>>> John Scoles wrote:
>>>
>>>
Ok I have patched up a solution I think will work across the board and
you
can find it here
http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
here are the details
ora_oci_batch
For 11g users you may encounter an error while using the execute_array
in
that it does not
return a full list of tuples. This seems to be a result in that a
statement
can only
have 'LOG ERRORS' or 'SAVE EXCEPTIONS'set, By setting this flag to a
value
should stop this
problem error.
For convenience I have added support for a 'ORA_DBD_OCI_BATCH'
environment variable that you can use at the OS level to set this
value. It can also be set as an attribute on both the Connect and
Prepare.
Unfortunately I can't test it (do not have an 11g box yet) so It will
stay
in the above branch until it is tested hopefully by you Scott
Cheers
John Scoles
--
See Pythian's Alex Gorbachev, co-author of "Expert Oracle Practices" at
NoCOUG Spring Conference May 20th.
Details, interview & book chapter in the May NoCOUG Journal:
http://bit.ly/alexnocoug
>>> I'm not sure why I seem to have ignored your mail but I just noticed it
>>> again - sorry for the delay.
>>>
>>> I checked out the branch you mentioned and
>>>
>>> export ORA_DBD_OCI_BATCH=1
>>>
>>> but 26exe_array still seems to fail for me:
>>>
>>>
>>
>> Sorry John, I meant to test earlier but its been a busy week.
>>
>> Fails for me as well.
>>
>> DB<7> x $dbh->{'ora_oci_batch'}
>> 0 1
>> DB<8> n
>> main::(../tst_exec_ary.pl:13): my $sth = $dbh->prepare("Insert into
>> TestArray Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY");
>> DB<8> n
>> main::(../tst_exec_ary.pl:15): $sth->bind_param_array(1, [ qw(One Uno Il
>> oNe) ]);
>> DB<8> n
>> main::(../tst_exec_ary.pl:16): $sth->bind_param_array(2, [ 2, 22, 0, 222
>> ]);
>> DB<8> n
>> main::(../tst_exec_ary.pl:17): $sth->bind_param_array(3, [ qw(20070101
>> 20080101 20090101 20060101) ]);
>> DB<8> n
>> main::(../tst_exec_ary.pl:21): $sth->execute_array({});
>> DB<8> n
>> DBD::Oracle::st execute_array failed: ORA-38909: DML Error logging is not
>> supported with BATCH ERROR mode (DBD ERROR: OCIStmtExecute) [for Statement
>> "Insert into TestArray Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY"] at
>> ../tst_exec_ary.pl line 21.
>> at ../tst_exec_ary.pl line 21
>>
>>
>>
>>> mar...@bragi:~/svn/dbd-oracle/branches/oci_batch$ prove -vb
>>> t/26exe_array.t
>>> t/26exe_array.t ..
>>> 1..17
>>> ok 1 - use DBI;
>>> ok 2 - The object isa DBI::db
>>> ok 3 - ... execute_array should return true
>>> ok 4 - ... we should have 10 tuple_status
>>> ok 5 - ... execute_array should return false
>>> ok 6 - ... we should have 10 tuple_status
>>> ok 7 - ... we should get text
>>> ok 8 - ... we should get -1
>>> ok 9 - ... we should get a warning
>>> ok 10 - ... execute_for_fetch should return true
>>> not ok 11 - ... we should have 19 tuple_status
>>>
>>> # Failed test '... we should have 19 tuple_status'
>>> # at t/26exe_array.t line 128.
>>> # got: 10
>>> # expected: 19
>>> ok 12 - ... execute_array should return flase
>>> ok 13 - ... we should have 10 tuple_status
>>> not ok 14 - ... we should have 48 rows
>>>
>>> # Failed test '... we should have 48 rows'
>>> # at t/26exe_array.t line 154.
>>> # got: 30
>>> # expected: 48
>>> ok 15 - ... execute_array should return true
>>> ok 16 - ... \#5 should be a warning
>>> ok 17 - ... we should have 10 tuple_status
>>> # Looks like you failed 2 tests of 17.
>>> Dubious, test returned 2 (wstat 512, 0x200)
>>> Failed 2/17 subtests
>>>
>>> Test Summary Report
>>> ---
>>> t/26exe_array.t (Wstat: 512 Tests: 17 Failed: 2)
>>> Failed tests: 11, 14
>>> Non-zero exit status: 2
>>> Files=1, Tests=17, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.05 cusr
>>> 0.01 csys = 0.09 CPU)
>>> Result: FAIL
>>>
>>> This was using oracle 11.1 server and 11.1 instant client.
>>>
>>> If I've not set the right thing let me know.
>>>
>>> Martin
>>>
>>>
>>
>>
>>
>
>
>
--
Catch Alex & Sheeri at ODTUG/Kaleidoscope - June 27 - July 1.
Hear Sheeri speak or email eve...@pythian.com to meet with Pythian.
Re: DBD::Oracle 11gr2 & ORA-38909
Ok I guess it is back to square 1 on this.
Unfortunetly no time to look at it today
Will write up a small test script and see if my patch actually does anything
You may hear from me in a few days
Cheers
John
Scott T. Hildreth wrote:
On Fri, 2010-05-21 at 09:23 +0100, Martin Evans wrote:
John Scoles wrote:
Ok I have patched up a solution I think will work across the board and you
can find it here
http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
here are the details
ora_oci_batch
For 11g users you may encounter an error while using the execute_array in
that it does not
return a full list of tuples. This seems to be a result in that a statement
can only
have 'LOG ERRORS' or 'SAVE EXCEPTIONS'set, By setting this flag to a value
should stop this
problem error.
For convenience I have added support for a 'ORA_DBD_OCI_BATCH'
environment variable that you can use at the OS level to set this
value. It can also be set as an attribute on both the Connect and Prepare.
Unfortunately I can't test it (do not have an 11g box yet) so It will stay
in the above branch until it is tested hopefully by you Scott
Cheers
John Scoles
--
See Pythian's Alex Gorbachev, co-author of "Expert Oracle Practices" at NoCOUG
Spring Conference May 20th.
Details, interview & book chapter in the May NoCOUG Journal:
http://bit.ly/alexnocoug
I'm not sure why I seem to have ignored your mail but I just noticed it
again - sorry for the delay.
I checked out the branch you mentioned and
export ORA_DBD_OCI_BATCH=1
but 26exe_array still seems to fail for me:
Sorry John, I meant to test earlier but its been a busy week.
Fails for me as well.
DB<7> x $dbh->{'ora_oci_batch'}
0 1
DB<8> n
main::(../tst_exec_ary.pl:13): my $sth = $dbh->prepare("Insert into TestArray
Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY");
DB<8> n
main::(../tst_exec_ary.pl:15): $sth->bind_param_array(1, [ qw(One Uno Il oNe)
]);
DB<8> n
main::(../tst_exec_ary.pl:16): $sth->bind_param_array(2, [ 2, 22, 0, 222 ]);
DB<8> n
main::(../tst_exec_ary.pl:17): $sth->bind_param_array(3, [ qw(20070101
20080101 20090101 20060101) ]);
DB<8> n
main::(../tst_exec_ary.pl:21): $sth->execute_array({});
DB<8> n
DBD::Oracle::st execute_array failed: ORA-38909: DML Error logging is not supported with
BATCH ERROR mode (DBD ERROR: OCIStmtExecute) [for Statement "Insert into TestArray
Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY"] at ../tst_exec_ary.pl line 21.
at ../tst_exec_ary.pl line 21
mar...@bragi:~/svn/dbd-oracle/branches/oci_batch$ prove -vb t/26exe_array.t
t/26exe_array.t ..
1..17
ok 1 - use DBI;
ok 2 - The object isa DBI::db
ok 3 - ... execute_array should return true
ok 4 - ... we should have 10 tuple_status
ok 5 - ... execute_array should return false
ok 6 - ... we should have 10 tuple_status
ok 7 - ... we should get text
ok 8 - ... we should get -1
ok 9 - ... we should get a warning
ok 10 - ... execute_for_fetch should return true
not ok 11 - ... we should have 19 tuple_status
# Failed test '... we should have 19 tuple_status'
# at t/26exe_array.t line 128.
# got: 10
# expected: 19
ok 12 - ... execute_array should return flase
ok 13 - ... we should have 10 tuple_status
not ok 14 - ... we should have 48 rows
# Failed test '... we should have 48 rows'
# at t/26exe_array.t line 154.
# got: 30
# expected: 48
ok 15 - ... execute_array should return true
ok 16 - ... \#5 should be a warning
ok 17 - ... we should have 10 tuple_status
# Looks like you failed 2 tests of 17.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/17 subtests
Test Summary Report
---
t/26exe_array.t (Wstat: 512 Tests: 17 Failed: 2)
Failed tests: 11, 14
Non-zero exit status: 2
Files=1, Tests=17, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.05 cusr
0.01 csys = 0.09 CPU)
Result: FAIL
This was using oracle 11.1 server and 11.1 instant client.
If I've not set the right thing let me know.
Martin
Re: DBD::Oracle 11gr2 & ORA-38909
On Fri, 2010-05-21 at 09:23 +0100, Martin Evans wrote:
> John Scoles wrote:
> > Ok I have patched up a solution I think will work across the board and you
> > can find it here
> >
> > http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
> >
> > here are the details
> >
> > ora_oci_batch
> >
> > For 11g users you may encounter an error while using the execute_array in
> > that it does not
> > return a full list of tuples. This seems to be a result in that a statement
> > can only
> > have 'LOG ERRORS' or 'SAVE EXCEPTIONS'set, By setting this flag to a value
> > should stop this
> > problem error.
> >
> > For convenience I have added support for a 'ORA_DBD_OCI_BATCH'
> > environment variable that you can use at the OS level to set this
> > value. It can also be set as an attribute on both the Connect and Prepare.
> >
> > Unfortunately I can't test it (do not have an 11g box yet) so It will stay
> > in the above branch until it is tested hopefully by you Scott
> >
> > Cheers
> > John Scoles
> >
> > --
> > See Pythian's Alex Gorbachev, co-author of "Expert Oracle Practices" at
> > NoCOUG Spring Conference May 20th.
> > Details, interview & book chapter in the May NoCOUG Journal:
> > http://bit.ly/alexnocoug
> >
>
> I'm not sure why I seem to have ignored your mail but I just noticed it
> again - sorry for the delay.
>
> I checked out the branch you mentioned and
>
> export ORA_DBD_OCI_BATCH=1
>
> but 26exe_array still seems to fail for me:
Sorry John, I meant to test earlier but its been a busy week.
Fails for me as well.
DB<7> x $dbh->{'ora_oci_batch'}
0 1
DB<8> n
main::(../tst_exec_ary.pl:13): my $sth = $dbh->prepare("Insert into TestArray
Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY");
DB<8> n
main::(../tst_exec_ary.pl:15): $sth->bind_param_array(1, [ qw(One Uno Il oNe)
]);
DB<8> n
main::(../tst_exec_ary.pl:16): $sth->bind_param_array(2, [ 2, 22, 0, 222 ]);
DB<8> n
main::(../tst_exec_ary.pl:17): $sth->bind_param_array(3, [ qw(20070101
20080101 20090101 20060101) ]);
DB<8> n
main::(../tst_exec_ary.pl:21): $sth->execute_array({});
DB<8> n
DBD::Oracle::st execute_array failed: ORA-38909: DML Error logging is not
supported with BATCH ERROR mode (DBD ERROR: OCIStmtExecute) [for Statement
"Insert into TestArray Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY"] at
../tst_exec_ary.pl line 21.
at ../tst_exec_ary.pl line 21
>
> mar...@bragi:~/svn/dbd-oracle/branches/oci_batch$ prove -vb t/26exe_array.t
> t/26exe_array.t ..
> 1..17
> ok 1 - use DBI;
> ok 2 - The object isa DBI::db
> ok 3 - ... execute_array should return true
> ok 4 - ... we should have 10 tuple_status
> ok 5 - ... execute_array should return false
> ok 6 - ... we should have 10 tuple_status
> ok 7 - ... we should get text
> ok 8 - ... we should get -1
> ok 9 - ... we should get a warning
> ok 10 - ... execute_for_fetch should return true
> not ok 11 - ... we should have 19 tuple_status
>
> # Failed test '... we should have 19 tuple_status'
> # at t/26exe_array.t line 128.
> # got: 10
> # expected: 19
> ok 12 - ... execute_array should return flase
> ok 13 - ... we should have 10 tuple_status
> not ok 14 - ... we should have 48 rows
>
> # Failed test '... we should have 48 rows'
> # at t/26exe_array.t line 154.
> # got: 30
> # expected: 48
> ok 15 - ... execute_array should return true
> ok 16 - ... \#5 should be a warning
> ok 17 - ... we should have 10 tuple_status
> # Looks like you failed 2 tests of 17.
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/17 subtests
>
> Test Summary Report
> ---
> t/26exe_array.t (Wstat: 512 Tests: 17 Failed: 2)
> Failed tests: 11, 14
> Non-zero exit status: 2
> Files=1, Tests=17, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.05 cusr
> 0.01 csys = 0.09 CPU)
> Result: FAIL
>
> This was using oracle 11.1 server and 11.1 instant client.
>
> If I've not set the right thing let me know.
>
> Martin
Re: DBD::Oracle 11gr2 & ORA-38909
John Scoles wrote: > Ok I have patched up a solution I think will work across the board and you > can find it here > > http://svn.perl.org/modules/dbd-oracle/branches/oci_batch > > here are the details > > ora_oci_batch > > For 11g users you may encounter an error while using the execute_array in > that it does not > return a full list of tuples. This seems to be a result in that a statement > can only > have 'LOG ERRORS' or 'SAVE EXCEPTIONS'set, By setting this flag to a value > should stop this > problem error. > > For convenience I have added support for a 'ORA_DBD_OCI_BATCH' > environment variable that you can use at the OS level to set this > value. It can also be set as an attribute on both the Connect and Prepare. > > Unfortunately I can't test it (do not have an 11g box yet) so It will stay > in the above branch until it is tested hopefully by you Scott > > Cheers > John Scoles > > -- > See Pythian's Alex Gorbachev, co-author of "Expert Oracle Practices" at > NoCOUG Spring Conference May 20th. > Details, interview & book chapter in the May NoCOUG Journal: > http://bit.ly/alexnocoug > I'm not sure why I seem to have ignored your mail but I just noticed it again - sorry for the delay. I checked out the branch you mentioned and export ORA_DBD_OCI_BATCH=1 but 26exe_array still seems to fail for me: mar...@bragi:~/svn/dbd-oracle/branches/oci_batch$ prove -vb t/26exe_array.t t/26exe_array.t .. 1..17 ok 1 - use DBI; ok 2 - The object isa DBI::db ok 3 - ... execute_array should return true ok 4 - ... we should have 10 tuple_status ok 5 - ... execute_array should return false ok 6 - ... we should have 10 tuple_status ok 7 - ... we should get text ok 8 - ... we should get -1 ok 9 - ... we should get a warning ok 10 - ... execute_for_fetch should return true not ok 11 - ... we should have 19 tuple_status # Failed test '... we should have 19 tuple_status' # at t/26exe_array.t line 128. # got: 10 # expected: 19 ok 12 - ... execute_array should return flase ok 13 - ... we should have 10 tuple_status not ok 14 - ... we should have 48 rows # Failed test '... we should have 48 rows' # at t/26exe_array.t line 154. # got: 30 # expected: 48 ok 15 - ... execute_array should return true ok 16 - ... \#5 should be a warning ok 17 - ... we should have 10 tuple_status # Looks like you failed 2 tests of 17. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/17 subtests Test Summary Report --- t/26exe_array.t (Wstat: 512 Tests: 17 Failed: 2) Failed tests: 11, 14 Non-zero exit status: 2 Files=1, Tests=17, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.05 cusr 0.01 csys = 0.09 CPU) Result: FAIL This was using oracle 11.1 server and 11.1 instant client. If I've not set the right thing let me know. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: Clarification sought on private_attribute_info WAS Re: DBD::Oracle 11gr2 & ORA-38909
[Sorry for the delay]
On the one hand, the DBI makes a distinction between "method attributes"
and "handle attributes. They're different things.
On the other hand, the handle constructor methods are a special case.
The method attributes passed to connect() are applied to the newly
created dbh as handle attributes.
The same _ought_ to be true of prepare() but isn't, sadly. This is one
of those areas of the DBI where the risk of breakage now far outweighs
the gains from trying to fix it.
So, to answer your question Martin, I'll update the docs to clarify that
it applies to handle attributes.
Tim.
On Fri, May 07, 2010 at 04:35:32PM +0100, Martin Evans wrote:
> Apologies for top posting but this is an old thread and I include it for
> reference but really I'd like some clarification from Tim as to whether
> the following is correct.
>
> As John states the DBI documentation says for private_attribute_info:
>
> "Returns a reference to a hash whose keys are the names of
> driver-private attributes available for the kind of handle (driver,
> database, statement) that the method was called on."
>
> My question is does this include attributes which may be specified on
> the prepare call when there is no separate store/fetch on the handle. e.g.,
>
> $h->prepare("select 1 from dual", {ora_parse_lang => 2});
>
> You cannot set ora_parse_lang on a $sth or retrieve it so should it be
> in private_attribute_info?
>
> I would like to know since if ora_parse_lang in DBD::Oracle should be in
> private_attribute_info when it cannot be independently stored or fetched
> then this impacts similar prepare attributes in DBD::ODBC.
>
> Martin
> --
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
>
>
> John Scoles wrote:
> >
> >
> > On Tue, Apr 6, 2010 at 4:51 AM, Martin Evans > > wrote:
> >
> > I haven't seen a reply to this yet but I've been on holiday so might
> > have missed it:
> >
> > Scott T. Hildreth wrote:
> > > On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> > >> We have run into an issue with array processing in 11g. The
> > developer
> > >> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> > >> This did not error out until we switched to 11g. The issue is
> > that only
> > >> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> > >> logged and error report with Oracle and after several posts back and
> > >> forth this is what they concluded,
> > >>
> > >>
> > ==
> > >> After investigation and discussion, development has closed the bug as
> > >> 'Not a Bug' with the following reason:
> > >>
> > >> "this is an expected behavior in 11g and the user needs to specify
> > >> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging',
> > but NOT
> > >> both together.
> > >> The batch error mode, in the context of this bug, is basically
> > referring
> > >> to the SAVE EXCEPTIONS clause.
> > >> It seems the code is trying to use both dml error logging and batch
> > >> error handling for the same insert. In that case, this is not a bug.
> > >>
> > >> For INSERT, the data errors are logged in an error logging table
> > (when
> > >> the dml error logging feature is used) or returned in batch error
> > >> handles (when using batch mode).
> > >> Since the error messages are available to the user in either
> > case, there
> > >> is no need to both log the error in the error logging table and
> > return
> > >> the errors in batch error handles,
> > >> and we require the user to specify one option or the other but
> > not both
> > >> in 11G.
> > >>
> > >> Both features exist in 10.x. For 11.x, users should change their
> > >> application to avoid the error.
> > >>
> > ==
> > >>
> > >> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> > >> batch mode. I found in dbdimp.c that the oci_mode is being set to
> > >> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was
> > planning
> > >> on setting it to OCI_BATCH_MODE and running a test to see if this
> > will
> > >> not error out. I report back when I have run the test, but I was
> > >> wondering what would be the best way to give the user the ability to
> > >> override the oci_mode.
> > >
> > > Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> > > attribute that will turn off the SAVE EXCEPTIONS. I'm looking for
> > some
> > > direction on how to add it to dbdimp.c. I haven't thought of a
> > name yet,
> > > but something like
> > >
> > > my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
> > >
> > > I assume I wou
Re: DBD::Oracle 11gr2 & ORA-38909
Ok I have patched up a solution I think will work across the board and you can find it here http://svn.perl.org/modules/dbd-oracle/branches/oci_batch here are the details ora_oci_batch For 11g users you may encounter an error while using the execute_array in that it does not return a full list of tuples. This seems to be a result in that a statement can only have 'LOG ERRORS' or 'SAVE EXCEPTIONS'set, By setting this flag to a value should stop this problem error. For convenience I have added support for a 'ORA_DBD_OCI_BATCH' environment variable that you can use at the OS level to set this value. It can also be set as an attribute on both the Connect and Prepare. Unfortunately I can't test it (do not have an 11g box yet) so It will stay in the above branch until it is tested hopefully by you Scott Cheers John Scoles -- See Pythian's Alex Gorbachev, co-author of "Expert Oracle Practices" at NoCOUG Spring Conference May 20th. Details, interview & book chapter in the May NoCOUG Journal: http://bit.ly/alexnocoug
Clarification sought on private_attribute_info WAS Re: DBD::Oracle 11gr2 & ORA-38909
Apologies for top posting but this is an old thread and I include it for
reference but really I'd like some clarification from Tim as to whether
the following is correct.
As John states the DBI documentation says for private_attribute_info:
"Returns a reference to a hash whose keys are the names of
driver-private attributes available for the kind of handle (driver,
database, statement) that the method was called on."
My question is does this include attributes which may be specified on
the prepare call when there is no separate store/fetch on the handle. e.g.,
$h->prepare("select 1 from dual", {ora_parse_lang => 2});
You cannot set ora_parse_lang on a $sth or retrieve it so should it be
in private_attribute_info?
I would like to know since if ora_parse_lang in DBD::Oracle should be in
private_attribute_info when it cannot be independently stored or fetched
then this impacts similar prepare attributes in DBD::ODBC.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
John Scoles wrote:
>
>
> On Tue, Apr 6, 2010 at 4:51 AM, Martin Evans > wrote:
>
> I haven't seen a reply to this yet but I've been on holiday so might
> have missed it:
>
> Scott T. Hildreth wrote:
> > On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> >> We have run into an issue with array processing in 11g. The
> developer
> >> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> >> This did not error out until we switched to 11g. The issue is
> that only
> >> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> >> logged and error report with Oracle and after several posts back and
> >> forth this is what they concluded,
> >>
> >>
> ==
> >> After investigation and discussion, development has closed the bug as
> >> 'Not a Bug' with the following reason:
> >>
> >> "this is an expected behavior in 11g and the user needs to specify
> >> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging',
> but NOT
> >> both together.
> >> The batch error mode, in the context of this bug, is basically
> referring
> >> to the SAVE EXCEPTIONS clause.
> >> It seems the code is trying to use both dml error logging and batch
> >> error handling for the same insert. In that case, this is not a bug.
> >>
> >> For INSERT, the data errors are logged in an error logging table
> (when
> >> the dml error logging feature is used) or returned in batch error
> >> handles (when using batch mode).
> >> Since the error messages are available to the user in either
> case, there
> >> is no need to both log the error in the error logging table and
> return
> >> the errors in batch error handles,
> >> and we require the user to specify one option or the other but
> not both
> >> in 11G.
> >>
> >> Both features exist in 10.x. For 11.x, users should change their
> >> application to avoid the error.
> >>
> ==
> >>
> >> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> >> batch mode. I found in dbdimp.c that the oci_mode is being set to
> >> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was
> planning
> >> on setting it to OCI_BATCH_MODE and running a test to see if this
> will
> >> not error out. I report back when I have run the test, but I was
> >> wondering what would be the best way to give the user the ability to
> >> override the oci_mode.
> >
> > Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> > attribute that will turn off the SAVE EXCEPTIONS. I'm looking for
> some
> > direction on how to add it to dbdimp.c. I haven't thought of a
> name yet,
> > but something like
> >
> > my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
> >
> > I assume I would have to add it to dbd_db_FETCH_attrib() and would
> I do
> > something like this in ora_st_execute_array(),
>
> Don't you mean dbd_st_FETCH_attrib as it is a statement level attribute
> not a connection one? Anyway, I don't think it is required unless you
> really want to get it back out in a Perl script.
>
> I don't even think you need to add it to a statements
> private_attribute_info but then when I checked Oracle.pm it appears a
> load of prepare flags have been added. I might be wrong here but since
> there is no way to get ora_parse_lang etc (prepare attributes) I don't
> think they should be in private_attribute_info.
>
> Well it should be in there along with the other ones I forgot to add;)
>
> if one looks at the dbi spec
>
>
> |private_attribute_info| <#___top>
>
> Returns a reference to a hash w
Re: DBD::Oracle 11gr2 & ORA-38909
On Tue, Apr 6, 2010 at 4:51 AM, Martin Evans wrote:
> I haven't seen a reply to this yet but I've been on holiday so might
> have missed it:
>
> Scott T. Hildreth wrote:
> > On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> >> We have run into an issue with array processing in 11g. The developer
> >> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> >> This did not error out until we switched to 11g. The issue is that only
> >> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> >> logged and error report with Oracle and after several posts back and
> >> forth this is what they concluded,
> >>
> >> ==
> >> After investigation and discussion, development has closed the bug as
> >> 'Not a Bug' with the following reason:
> >>
> >> "this is an expected behavior in 11g and the user needs to specify
> >> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT
> >> both together.
> >> The batch error mode, in the context of this bug, is basically referring
> >> to the SAVE EXCEPTIONS clause.
> >> It seems the code is trying to use both dml error logging and batch
> >> error handling for the same insert. In that case, this is not a bug.
> >>
> >> For INSERT, the data errors are logged in an error logging table (when
> >> the dml error logging feature is used) or returned in batch error
> >> handles (when using batch mode).
> >> Since the error messages are available to the user in either case, there
> >> is no need to both log the error in the error logging table and return
> >> the errors in batch error handles,
> >> and we require the user to specify one option or the other but not both
> >> in 11G.
> >>
> >> Both features exist in 10.x. For 11.x, users should change their
> >> application to avoid the error.
> >> ==
> >>
> >> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> >> batch mode. I found in dbdimp.c that the oci_mode is being set to
> >> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning
> >> on setting it to OCI_BATCH_MODE and running a test to see if this will
> >> not error out. I report back when I have run the test, but I was
> >> wondering what would be the best way to give the user the ability to
> >> override the oci_mode.
> >
> > Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> > attribute that will turn off the SAVE EXCEPTIONS. I'm looking for some
> > direction on how to add it to dbdimp.c. I haven't thought of a name yet,
> > but something like
> >
> > my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
> >
> > I assume I would have to add it to dbd_db_FETCH_attrib() and would I do
> > something like this in ora_st_execute_array(),
>
> Don't you mean dbd_st_FETCH_attrib as it is a statement level attribute
> not a connection one? Anyway, I don't think it is required unless you
> really want to get it back out in a Perl script.
>
> I don't even think you need to add it to a statements
> private_attribute_info but then when I checked Oracle.pm it appears a
> load of prepare flags have been added. I might be wrong here but since
> there is no way to get ora_parse_lang etc (prepare attributes) I don't
> think they should be in private_attribute_info.
>
> Well it should be in there along with the other ones I forgot to add;)
if one looks at the dbi spec
private_attribute_info <#___top>
Returns a reference to a hash whose keys are the names of driver-private
attributes available for the kind of handle (driver, database, statement)
that the method was called on.
The values should be undef. Meanings may be assigned to particular values in
future.
> perl -e 'use DBI;$h =
> DBI->connect("dbi:Oracle:host=xxx;sid=yyy","xxx","yyy"); $s =
> $h->prepare("select 1 from dual", {ora_parse_lang => 2}); print
> $s->{ora_parse_lang};'
>
> prints nothing as you'd expect as there is no way to get ora_parse_lang.
>
>
as it should be since you are setting these why would you want to get their
values??
> > if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
> > DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
> ora_oci_err_mode);
>
> I don't understand why you need it in ora_st_execute_array - the
> statement has already been parsed by then. Do you mean dbd_st_prepare in
> oci8.c.
>
> >
> > Thanks,
> > Scott
> >
> >
> >> An attribute in the prepare method?
> >>
> >> Thanks,
> >> Scott
> >
> >
>
> Martin
> --
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
>
Anyway as a solution to the 'OCI_BATCH_MODE' problem I will add it in as
like id did for
ora_ncs_buff_mtpl so one can set it at the ENV, connect and statement
level so I can cover of any situation that may require a solution
Look for it as ora_oci_batch and ORA_DBD_OCI_BATCH for the env
Cheers john Scoles
--
See Pythian's
Re: DBD::Oracle 11gr2 & ORA-38909
On Tue, 2010-04-06 at 09:51 +0100, Martin Evans wrote:
> I haven't seen a reply to this yet but I've been on holiday so might
> have missed it:
>
> Scott T. Hildreth wrote:
> > On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> >> We have run into an issue with array processing in 11g. The developer
> >> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> >> This did not error out until we switched to 11g. The issue is that only
> >> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> >> logged and error report with Oracle and after several posts back and
> >> forth this is what they concluded,
> >>
> >> ==
> >> After investigation and discussion, development has closed the bug as
> >> 'Not a Bug' with the following reason:
> >>
> >> "this is an expected behavior in 11g and the user needs to specify
> >> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT
> >> both together.
> >> The batch error mode, in the context of this bug, is basically referring
> >> to the SAVE EXCEPTIONS clause.
> >> It seems the code is trying to use both dml error logging and batch
> >> error handling for the same insert. In that case, this is not a bug.
> >>
> >> For INSERT, the data errors are logged in an error logging table (when
> >> the dml error logging feature is used) or returned in batch error
> >> handles (when using batch mode).
> >> Since the error messages are available to the user in either case, there
> >> is no need to both log the error in the error logging table and return
> >> the errors in batch error handles,
> >> and we require the user to specify one option or the other but not both
> >> in 11G.
> >>
> >> Both features exist in 10.x. For 11.x, users should change their
> >> application to avoid the error.
> >> ==
> >>
> >> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> >> batch mode. I found in dbdimp.c that the oci_mode is being set to
> >> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning
> >> on setting it to OCI_BATCH_MODE and running a test to see if this will
> >> not error out. I report back when I have run the test, but I was
> >> wondering what would be the best way to give the user the ability to
> >> override the oci_mode.
> >
> > Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> > attribute that will turn off the SAVE EXCEPTIONS. I'm looking for some
> > direction on how to add it to dbdimp.c. I haven't thought of a name yet,
> > but something like
> >
> > my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
> >
> > I assume I would have to add it to dbd_db_FETCH_attrib() and would I do
> > something like this in ora_st_execute_array(),
>
> Don't you mean dbd_st_FETCH_attrib as it is a statement level attribute
> not a connection one?
Yes.
> Anyway, I don't think it is required unless you
> really want to get it back out in a Perl script.
>
> I don't even think you need to add it to a statements
> private_attribute_info but then when I checked Oracle.pm it appears a
> load of prepare flags have been added. I might be wrong here but since
> there is no way to get ora_parse_lang etc (prepare attributes) I don't
> think they should be in private_attribute_info.
>
> perl -e 'use DBI;$h =
> DBI->connect("dbi:Oracle:host=xxx;sid=yyy","xxx","yyy"); $s =
> $h->prepare("select 1 from dual", {ora_parse_lang => 2}); print
> $s->{ora_parse_lang};'
>
> prints nothing as you'd expect as there is no way to get ora_parse_lang.
>
> > if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
> > DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
> > ora_oci_err_mode);
>
> I don't understand why you need it in ora_st_execute_array - the
> statement has already been parsed by then.
I don't either, I was looking at other attributes and how they are in
the code. That's why I asked for direction, :-)
> Do you mean dbd_st_prepare in
> oci8.c.
I think John is going to add this attribute, but I will give it a whirl
for the sake of learning more about DBD::Oracle.
Thanks.
>
> >
> > Thanks,
> > Scott
> >
> >
> >> An attribute in the prepare method?
> >>
> >> Thanks,
> >> Scott
> >
> >
>
> Martin
Re: DBD::Oracle 11gr2 & ORA-38909
I haven't seen a reply to this yet but I've been on holiday so might
have missed it:
Scott T. Hildreth wrote:
> On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
>> We have run into an issue with array processing in 11g. The developer
>> was using execute_array and his sql statement had 'LOG ERRORS' in it.
>> This did not error out until we switched to 11g. The issue is that only
>> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
>> logged and error report with Oracle and after several posts back and
>> forth this is what they concluded,
>>
>> ==
>> After investigation and discussion, development has closed the bug as
>> 'Not a Bug' with the following reason:
>>
>> "this is an expected behavior in 11g and the user needs to specify
>> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT
>> both together.
>> The batch error mode, in the context of this bug, is basically referring
>> to the SAVE EXCEPTIONS clause.
>> It seems the code is trying to use both dml error logging and batch
>> error handling for the same insert. In that case, this is not a bug.
>>
>> For INSERT, the data errors are logged in an error logging table (when
>> the dml error logging feature is used) or returned in batch error
>> handles (when using batch mode).
>> Since the error messages are available to the user in either case, there
>> is no need to both log the error in the error logging table and return
>> the errors in batch error handles,
>> and we require the user to specify one option or the other but not both
>> in 11G.
>>
>> Both features exist in 10.x. For 11.x, users should change their
>> application to avoid the error.
>> ==
>>
>> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
>> batch mode. I found in dbdimp.c that the oci_mode is being set to
>> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning
>> on setting it to OCI_BATCH_MODE and running a test to see if this will
>> not error out. I report back when I have run the test, but I was
>> wondering what would be the best way to give the user the ability to
>> override the oci_mode.
>
> Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> attribute that will turn off the SAVE EXCEPTIONS. I'm looking for some
> direction on how to add it to dbdimp.c. I haven't thought of a name yet,
> but something like
>
> my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
>
> I assume I would have to add it to dbd_db_FETCH_attrib() and would I do
> something like this in ora_st_execute_array(),
Don't you mean dbd_st_FETCH_attrib as it is a statement level attribute
not a connection one? Anyway, I don't think it is required unless you
really want to get it back out in a Perl script.
I don't even think you need to add it to a statements
private_attribute_info but then when I checked Oracle.pm it appears a
load of prepare flags have been added. I might be wrong here but since
there is no way to get ora_parse_lang etc (prepare attributes) I don't
think they should be in private_attribute_info.
perl -e 'use DBI;$h =
DBI->connect("dbi:Oracle:host=xxx;sid=yyy","xxx","yyy"); $s =
$h->prepare("select 1 from dual", {ora_parse_lang => 2}); print
$s->{ora_parse_lang};'
prints nothing as you'd expect as there is no way to get ora_parse_lang.
> if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
> DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
> ora_oci_err_mode);
I don't understand why you need it in ora_st_execute_array - the
statement has already been parsed by then. Do you mean dbd_st_prepare in
oci8.c.
>
> Thanks,
> Scott
>
>
>> An attribute in the prepare method?
>>
>> Thanks,
>> Scott
>
>
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Re: DBD::Oracle 11gr2 & ORA-38909
On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> We have run into an issue with array processing in 11g. The developer
> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> This did not error out until we switched to 11g. The issue is that only
> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> logged and error report with Oracle and after several posts back and
> forth this is what they concluded,
>
> ==
> After investigation and discussion, development has closed the bug as
> 'Not a Bug' with the following reason:
>
> "this is an expected behavior in 11g and the user needs to specify
> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT
> both together.
> The batch error mode, in the context of this bug, is basically referring
> to the SAVE EXCEPTIONS clause.
> It seems the code is trying to use both dml error logging and batch
> error handling for the same insert. In that case, this is not a bug.
>
> For INSERT, the data errors are logged in an error logging table (when
> the dml error logging feature is used) or returned in batch error
> handles (when using batch mode).
> Since the error messages are available to the user in either case, there
> is no need to both log the error in the error logging table and return
> the errors in batch error handles,
> and we require the user to specify one option or the other but not both
> in 11G.
>
> Both features exist in 10.x. For 11.x, users should change their
> application to avoid the error.
> ==
>
> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> batch mode. I found in dbdimp.c that the oci_mode is being set to
> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning
> on setting it to OCI_BATCH_MODE and running a test to see if this will
> not error out. I report back when I have run the test, but I was
> wondering what would be the best way to give the user the ability to
> override the oci_mode.
Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
attribute that will turn off the SAVE EXCEPTIONS. I'm looking for some
direction on how to add it to dbdimp.c. I haven't thought of a name yet,
but something like
my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
I assume I would have to add it to dbd_db_FETCH_attrib() and would I do
something like this in ora_st_execute_array(),
if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
ora_oci_err_mode);
Thanks,
Scott
> An attribute in the prepare method?
>
> Thanks,
> Scott
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
Tim Bunce wrote:
>
> Post a diff and I'll review it for you. The code you appended previously
> looks ok.
Attached is a diff for DBD::Oracle based on subversion this morning (the
diffs for oci8.c may be a little difficult to read due to the large
indentation of the surrounding code and there are some additional
changes to fix comments). It adds support for DiscardString and
StrictlyTyped bind_col attributes and casting via sql_type_cast. Most
(all relevant) changes are conditional on a DBI with these features.
I have verified these changes work with Oracle 11 and DBD::Oracle from
subversion however, I note some lob tests were failing in DBD::Oracle
before my changes were applied.
There seem to be a large number of warnings compiling DBD::Oracle from
subversion but I've not touched any of them preferring to keep the patch
restricted to its purpose.
The issue with the SQL_DECIMAL return in sql_type_castsvpv still exists
(the NV_PRESERVES_UV issue) - I have not had time to look into this
properly as yet.
All comments appreciated.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Index: oci8.c
===
--- oci8.c (revision 13624)
+++ oci8.c (working copy)
@@ -431,7 +431,7 @@
case OCI_ATTR_FSPRECISION OCI_ATTR_PDSCL:return "";*/
/* fs prec for datetime data types */
case OCI_ATTR_PDPRC:return "OCI_ATTR_PDPRC"; /* packed decimal format
- case OCI_ATTR_LFPRECISION OCI_ATTR_PDPRC: return "";
+case OCI_ATTR_LFPRECISION OCI_ATTR_PDPRC: return ""; */
/* fs prec for datetime data types */
case OCI_ATTR_PARAM_COUNT: return "OCI_ATTR_PARAM_COUNT"; /* number of column in the select list */
case OCI_ATTR_ROWID:return "OCI_ATTR_ROWID"; /* the rowid */
@@ -513,7 +513,7 @@
case OCI_ATTR_COL_COUNT: return "OCI_ATTR_COL_COUNT";/* columns of column array
processed so far. */
case OCI_ATTR_STREAM_OFFSET: return "OCI_ATTR_STREAM_OFFSET"; /* str off of last row processed
- case OCI_ATTR_SHARED_HEAPALLO:return "";/* Shared Heap Allocation Size */
+ case OCI_ATTR_SHARED_HEAPALLO:return "";*//* Shared Heap Allocation Size */
case OCI_ATTR_SERVER_GROUP: return "OCI_ATTR_SERVER_GROUP";/* server group name */
@@ -686,7 +686,7 @@
/* Attr to allow setting of the stream version PRIOR to calling Prepare */
case OCI_ATTR_DIRPATH_STREAM_VERSION: return "OCI_ATTR_DIRPATH_STREAM_VERSION"; /* version of the stream
- case OCI_ATTR_RESERVED_11:return "OCI_ATTR_RESERVED_11"; /* reserved */
+ case OCI_ATTR_RESERVED_11:return "OCI_ATTR_RESERVED_11";*/ /* reserved */
case OCI_ATTR_RESERVED_12: return "OCI_ATTR_RESERVED_12"; /* reserved */
case OCI_ATTR_RESERVED_13: return "OCI_ATTR_RESERVED_13"; /* reserved */
@@ -2668,7 +2668,7 @@
-/*static int /* --- Setup the row cache for this sth --- */
+static int /* --- Setup the row cache for this sth --- */
sth_set_row_cache(SV *h, imp_sth_t *imp_sth, int max_cache_rows, int num_fields, int has_longs)
{
dTHX;
@@ -3742,10 +3742,38 @@
while(datalen && p[datalen - 1]==' ')
--datalen;
}
- sv_setpvn(sv, p, (STRLEN)datalen);
- if (CSFORM_IMPLIES_UTF8(fbh->csform) ){
- SvUTF8_on(sv);
- }
+sv_setpvn(sv, p, (STRLEN)datalen);
+#if DBISTATE_VERSION > 94
+/* DBIXS_REVISION > 13590 */
+/* If a bind type was specified we use DBI's sql_type_cast
+ to cast it - currently only number types are handled */
+if (fbh->req_type != 0) {
+int sts;
+D_imp_xxh(sth);
+char errstr[256];
+
+sts = DBIc_DBISTATE(imp_sth)->sql_type_cast_svpv(
+aTHX_ sv, fbh->req_type, fbh->bind_flags, NULL);
+if (sts == 0) {
+sprintf(errstr,
+"over/under flow converting column %d to type %ld",
+i+1, fbh->req_type);
+oci_error(sth, imp_sth->errhp, OCI_ERROR, errstr);
+return Nullav;
+
+} else if (sts == -2) {
+sprintf(errstr,
+"unsupported bind type %ld for column %d",
+
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
On 11/27/2009 01:03 PM, Greg Sabino Mullane wrote: > I'd opine that since we're dealing with databases holding Important Things, > the default should be to throw an error and make people flip a switch > to get lax mode. A large warning in the upgreade notes should suffice for > anyone transitioning. > FWIW, Many hosting companies do not send out upgrade notes to their customers when upgrading some random Perl module. Many people do not read the entire release notes when upgrading their OS. Many people do not go looking for release notes before doing a 'sudo cpan install Module' :) So I do not know if just an upgrade warning would suffice for the majority of people. I was about to say that I agree with the stricter being the default, and that there should at least be a transition period. But then I got to thinking What percentage of the databases out there are actually holding "Important Things"? I suspect that the number of databases with important data are far outweighed by those that contain nothing but trivial data, alas. -r
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
Apologies if it seems this change is stalled, I've been extremely busy attempting to keep the wolf from the door. I will be back on it to finish it in the next few days. I've so far: o documented change in trunk for bind_col (edited by Tim) o documented change in trunk for DBI::DBD o fixed a problem in sql_type_cast o written test cases for sql_type_cast in trunk As far as I am aware there are four outstanding issues: o 2 of the tests I submitted fail - sql_type_cast for double - I got some input from perl monks and some guidance from Tim but I've not properly looked at any of it yet. o I've not posted a revised patch for DBD::Oracle using this stuff. o I've not changed DBD::ODBC (which will wait until DBD::Oracle is finalised) o I've not got a commit bit on DBD::Oracle - not the end of the world as I'll post a patch but it would be nice. Sorry about lack of progress but I've been /really/ busy with paid work and with bugs in other Perl modules that were more important to our project right now. Martin
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
On Sat, Nov 28, 2009 at 11:05:31AM +0100, H.Merijn Brand wrote:
> > >
> > > Does anyone know if there are other databases that have mapping issues
> > > with
> > > integers and Perlish integers other than Oracle? Just curious, as I only
> > > personally know how a handful deal with ints internally.
> >
> > DBD::SQLite returns only strings, along with most of the pure-perl
> > drivers, like DBD::CSV.
>
> The plan is still in my head to convert PV("1"\0) to IV(1) if the field
> type is numeric on fetch. Low priority though. Probably needs some work
> in DBD::File
Well, if this was done:
> > Which makes me wonder if $sth->_set_fbav(\...@row), which is used by most
> > pure-perl drivers to store each row, should call sql_type_cast()
> > automatically.
then it would take no work in DBD::File at all. Applications that
actually want IV/UV/NV's for some columns could simply use bind_col() to
ask for it. Also, being done in C, it would also be much faster than a
pure-perl addition to DBD::File.
Tim.
p.s. Seems like there's a reasonable case for restoring the old initial
\%attr of bind_columns() method: $sth->bind_columns({ TYPE => SQL_NUMERIC });
The 'harmless' nature of the SQL_NUMERIC semantics we've adopted make
that quite useful.
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
On Sat, 28 Nov 2009 00:43:48 +, Tim Bunce
wrote:
> On Fri, Nov 27, 2009 at 06:03:29PM -, Greg Sabino Mullane wrote:
> >
> > > I'm mostly settled on DBIstcf_STRICT _not_ being the default.
> > > So 'loosely typed' will be the default and people who want an error
> > > if the type can't be cast safely will need to use StrictlyTyped => 1.
> > >
> > > I'm (slightly) open to persuasion, but that seems to fit the general
> > > philosophy of perl and the DBI better. It also makes transition easier
> > > for anyone who happens to have code that calls bind_column with an SQL
> > > type.
> >
> > I'd opine that since we're dealing with databases holding Important Things,
> > the default should be to throw an error and make people flip a switch
> > to get lax mode.
>
> Umm, if the database holds Important Things one could opine that perl
> should trust the Important Things that are already in the database.
> We can argue it either way.
>
> A compromise might be to default to strict (for SQL_INTEGER and
> SQL_DOUBLE) but make SQL_NUMERIC immune from strict.
>
> > > o Although my primary impetus for doing this is I need it in DBD::Oracle
> > > I would plan to do something similar in DBD::ODBC once this stuff is
> > > committed.
> >
> > Does anyone know if there are other databases that have mapping issues with
> > integers and Perlish integers other than Oracle? Just curious, as I only
> > personally know how a handful deal with ints internally.
>
> DBD::SQLite returns only strings, along with most of the pure-perl
> drivers, like DBD::CSV.
The plan is still in my head to convert PV("1"\0) to IV(1) if the field
type is numeric on fetch. Low priority though. Probably needs some work
in DBD::File
> Which makes me wonder if $sth->_set_fbav(\...@row), which is used by most
> pure-perl drivers to store each row, should call sql_type_cast()
> automatically.
>
> Tim.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
On Fri, Nov 27, 2009 at 06:03:29PM -, Greg Sabino Mullane wrote: > > > I'm mostly settled on DBIstcf_STRICT _not_ being the default. > > So 'loosely typed' will be the default and people who want an error > > if the type can't be cast safely will need to use StrictlyTyped => 1. > > > > I'm (slightly) open to persuasion, but that seems to fit the general > > philosophy of perl and the DBI better. It also makes transition easier > > for anyone who happens to have code that calls bind_column with an SQL type. > > I'd opine that since we're dealing with databases holding Important Things, > the default should be to throw an error and make people flip a switch > to get lax mode. Umm, if the database holds Important Things one could opine that perl should trust the Important Things that are already in the database. We can argue it either way. A compromise might be to default to strict (for SQL_INTEGER and SQL_DOUBLE) but make SQL_NUMERIC immune from strict. > > o Although my primary impetus for doing this is I need it in DBD::Oracle > > I would plan to do something similar in DBD::ODBC once this stuff is > > committed. > > Does anyone know if there are other databases that have mapping issues with > integers and Perlish integers other than Oracle? Just curious, as I only > personally know how a handful deal with ints internally. DBD::SQLite returns only strings, along with most of the pure-perl drivers, like DBD::CSV. Which makes me wonder if $sth->_set_fbav(\...@row), which is used by most pure-perl drivers to store each row, should call sql_type_cast() automatically. Tim.
