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
h.m.br...@xs4all.nl wrote:
On Wed, 31 Dec 2014 16:58:02 +0100, H.Merijn Brand
h.m.br...@xs4all.nl 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 foo where d_foo = 111
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:
Re: DBD::Oracle sometimes return wrong PRECISION
On Wed, 31 Dec 2014 16:58:02 +0100, H.Merijn Brand
h.m.br...@xs4all.nl 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 Wed, 21 May 2014 17:28:53 -0700, Christopher Jones
christopher.jo...@oracle.com wrote:
On 05/19/2014 01:48 PM, H.Merijn Brand wrote:
On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones
christopher.jo...@oracle.com 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/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
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 christopher.jo...@oracle.com wrote: On 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones christopher.jo...@oracle.com 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 Thu, 22 May 2014 07:49:15 -0700, Christopher Jones christopher.jo...@oracle.com wrote: On 5/21/14, 11:03 PM, H.Merijn Brand wrote: On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones christopher.jo...@oracle.com wrote: On 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones christopher.jo...@oracle.com 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 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones christopher.jo...@oracle.com 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 christopher.jo...@oracle.com 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 christopher.jo...@oracle.com 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 christopher.jo...@oracle.com 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
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)
^
dbdimp.h:302:7:
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 13:38:38 +0200, H.Merijn Brand h.m.br...@xs4all.nl 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 format
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 1.72 fail
On Tue, 15 Apr 2014 11:06:47 -0400, Yanick Champoux
champ...@pythian.com 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, 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 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 Tue, 15 Apr 2014 10:33:19 -0700, Christopher Jones christopher.jo...@oracle.com 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 4/15/14, 10:56 AM, H.Merijn Brand wrote: On Tue, 15 Apr 2014 10:33:19 -0700, Christopher Jones christopher.jo...@oracle.com 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 - 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
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 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 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 Sun, 24 Jun 2012 11:25:00 +0100, Martin J. Evans martin.ev...@easysoft.com 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 RTs a summary and request for help
On Sun, 24 Jun 2012 14:26:13 +0200, H.Merijn Brand h.m.br...@xs4all.nl wrote: On Sun, 24 Jun 2012 11:25:00 +0100, Martin J. Evans martin.ev...@easysoft.com 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 24/06/2012 13:26, H.Merijn Brand wrote: On Sun, 24 Jun 2012 11:25:00 +0100, Martin J. Evans martin.ev...@easysoft.com 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 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 12-03-11 11:48 AM, H.Merijn Brand wrote: On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux yan...@babyl.dyndns.org 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 Mon, 12 Mar 2012 16:02:46 -0400, Yanick Champoux yan...@babyl.dyndns.org wrote: On 12-03-11 11:48 AM, H.Merijn Brand wrote: On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux yan...@babyl.dyndns.org 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
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 1.40
On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux yan...@babyl.dyndns.org 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 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
champ...@pythian.com 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 Mon, 27 Feb 2012 09:57:33 -0500, Yanick Champoux
champ...@pythian.com wrote:
On 02/27/12 02:02, H.Merijn Brand wrote:
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
champ...@pythian.com 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
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 v1.39_00 is out
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
champ...@pythian.com 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
Yanick Champoux yanick.champ...@gmail.com 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, 10 Feb 2012 14:30:03 +, Charles Jardine c...@cam.ac.uk 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 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;), 18, '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 09:56:59 -0500, Yanick Champoux yanick.champ...@gmail.com 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;), 18, '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: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 10:22:20 -0500, Yanick Champoux yanick.champ...@gmail.com 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 10/02/12 14:56, H.Merijn Brand wrote: On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine c...@cam.ac.uk 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 07:03:09PM +0100, H.Merijn Brand wrote: On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine c...@cam.ac.uk 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 v1.32 and v1.33_00 on their way to CPAN
On Tue, 18 Oct 2011 13:15:58 -0400, Yanick Champoux
champ...@pythian.com 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 17/02/11 12:34, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, H.Merijn Brand
h.m.br...@xs4all.nl 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 12:00, John Scoles wrote:
On Wed, Feb 16, 2011 at 5:45 AM, Martin J. Evans
martin.ev...@easysoft.com 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
a
href=http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip;DBD-Oracle-1.28-RC1.zip/A
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
strongora_driver_name/strong
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
strongora_client_info/strong
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.
strongora_client_identifier/strong
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.
strongora_action/strong
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
strongora_connect_with_default_signals/strong
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 alt;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#039;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
Re: DBD::Oracle Release Candidate 1
On Wed, 16 Feb 2011 12:32:12 +0100, H.Merijn Brand
h.m.br...@xs4all.nl 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 17/02/2011 7:34 AM, H.Merijn Brand wrote:
On Wed, 16 Feb 2011 12:32:12 +0100, H.Merijn Brand
h.m.br...@xs4all.nl 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 16/02/11 11:32, H.Merijn Brand wrote: On Fri, 11 Feb 2011 13:43:34 -0500, John Scolessco...@pythian.com 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 a href=http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip;DBD-Oracle-1.28-RC1.zip/A 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 ... snipped Merijn's results 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 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
a
href=http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip;DBD-Oracle-1.28-RC1.zip/A
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
strongora_driver_name/strong
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
strongora_client_info/strong
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.
strongora_client_identifier/strong
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.
strongora_action/strong
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
strongora_connect_with_default_signals/strong
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 lt;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#039;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
Re: DBD::Oracle Release Candidate 1
On Fri, 11 Feb 2011 13:43:34 -0500, John Scoles sco...@pythian.com 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 a href=http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip;DBD-Oracle-1.28-RC1.zip/A 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
Re: DBD::Oracle Release Candidate 1
On Fri, 11 Feb 2011 13:43:34 -0500, John Scoles sco...@pythian.com
wrote:
Here is the latest and greatest DBD::Oracle for your programming pleasure.
You can find the Zip file here
a
href=http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip;DBD-Oracle-1.28-RC1.zip/A
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 'unset', 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
Re: DBD::Oracle Release Candidate 1
On Wed, Feb 16, 2011 at 5:45 AM, Martin J. Evans
martin.ev...@easysoft.com 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
a
href=http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip;DBD-Oracle-1.28-RC1.zip/A
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
strongora_driver_name/strong
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
strongora_client_info/strong
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.
strongora_client_identifier/strong
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.
strongora_action/strong
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
strongora_connect_with_default_signals/strong
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 lt;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#039;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
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 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 - 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 Fri, 14 Jan 2011 14:56:46 +, Martin J. Evans martin.ev...@easysoft.com 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 15:01, H.Merijn Brand wrote: On Fri, 14 Jan 2011 14:56:46 +, Martin J. Evans martin.ev...@easysoft.com 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 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 martin.ev...@easysoft.com 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 Fri, 14 Jan 2011 15:21:39 +, Martin J. Evans martin.ev...@easysoft.com wrote: On 14/01/11 15:01, H.Merijn Brand wrote: On Fri, 14 Jan 2011 14:56:46 +, Martin J. Evans martin.ev...@easysoft.com 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 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 t...@samasher.com
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 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
--
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 jpz-p...@adelton.comwrote:
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
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 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 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 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 Fri, 06 Aug 2010 09:56:36 +0100, Charles Jardine c...@cam.ac.uk 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 Thu, 5 Aug 2010 13:49:57 +0200, H.Merijn Brand h.m.br...@xs4all.nl 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
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 lu...@unixsol.org 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 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 sco...@pythian.com 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.
DB7 x $dbh-{'ora_oci_batch'}
0 1
DB8 n
main::(../tst_exec_ary.pl:13): my $sth = $dbh-prepare(Insert into
TestArray Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY);
DB8 n
main::(../tst_exec_ary.pl:15): $sth-bind_param_array(1, [ qw(One Uno Il
oNe) ]);
DB8 n
main::(../tst_exec_ary.pl:16): $sth-bind_param_array(2, [ 2, 22, 0, 222
]);
DB8 n
main::(../tst_exec_ary.pl:17): $sth-bind_param_array(3, [ qw(20070101
20080101 20090101 20060101) ]);
DB8 n
main::(../tst_exec_ary.pl:21): $sth-execute_array({});
DB8 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
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: 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.
DB7 x $dbh-{'ora_oci_batch'}
0 1
DB8 n
main::(../tst_exec_ary.pl:13): my $sth = $dbh-prepare(Insert into TestArray
Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY);
DB8 n
main::(../tst_exec_ary.pl:15): $sth-bind_param_array(1, [ qw(One Uno Il oNe)
]);
DB8 n
main::(../tst_exec_ary.pl:16): $sth-bind_param_array(2, [ 2, 22, 0, 222 ]);
DB8 n
main::(../tst_exec_ary.pl:17): $sth-bind_param_array(3, [ qw(20070101
20080101 20090101 20060101) ]);
DB8 n
main::(../tst_exec_ary.pl:21): $sth-execute_array({});
DB8 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
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.
DB7 x $dbh-{'ora_oci_batch'}
0 1
DB8 n
main::(../tst_exec_ary.pl:13): my $sth = $dbh-prepare(Insert into TestArray
Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY);
DB8 n
main::(../tst_exec_ary.pl:15): $sth-bind_param_array(1, [ qw(One Uno Il oNe)
]);
DB8 n
main::(../tst_exec_ary.pl:16): $sth-bind_param_array(2, [ 2, 22, 0, 222 ]);
DB8 n
main::(../tst_exec_ary.pl:17): $sth-bind_param_array(3, [ qw(20070101
20080101 20090101 20060101) ]);
DB8 n
main::(../tst_exec_ary.pl:21): $sth-execute_array({});
DB8 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: 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 martin.ev...@easysoft.com
mailto:martin.ev...@easysoft.com 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
Re: DBD::Oracle 11gr2 ORA-38909
On Tue, Apr 6, 2010 at 4:51 AM, Martin Evans martin.ev...@easysoft.comwrote:
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 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 martin.ev...@easysoft.com
mailto:martin.ev...@easysoft.com 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
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
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 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
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
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
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,
+fbh-req_type, i+1);
+
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-1.23 Makefile.PL patch
On Fri, 27 Nov 2009 10:21:05 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: It seems I can't post attachments to the list, so here's the patch inline: Looks sane to me, but I'm not the DBD::Oracle maintainer :) While you're at it, I'd like to see some more changes: * make /usr/share/oracle not hardcoded but variable * make Instant Client work on windows too (Windows instant client works fine with the current Makefile.PL if installed on C:\Oracle\instantclient_11_1, but it does NOT work at all when installed in C:\Program Files\Oracle\... due to the space (I tried yesterday with the newest Strawberry) --- ../DBD-Oracle-1.23-3oaWaD/Makefile.PL 2009-04-29 10:04:24.0 -0500 +++ Makefile.PL 2009-11-23 16:18:31.0 -0600 @@ -1055,14 +1055,19 @@ 'proc/lib/proc.mk', 'proc16/lib/proc16.mk', ); -my @mk_oci = ( +my @mk_oci32 = ( + 'rdbms/demo/demo_rdbms32.mk' +); +my @mk_oci64 = ( 'rdbms/demo/demo_xe.mk', 'rdbms/lib/oracle.mk', 'rdbms/demo/oracle.mk', 'rdbms/demo/demo_rdbms.mk', + 'rdbms/demo/demo_rdbms64.mk', 'rdbms/lib/ins_rdbms.mk' #Oracle 11 full client for 64 bit and maybe 32 bit?? ); +my @mk_oci = perl_is_64bit() ? @mk_oci64 : @mk_oci32; $client_version and push @mk_proc,# Oracle Instant Client /usr/share/oracle/$client_version/client/demo.mk, /usr/share/oracle/$client_version/client64/demo.mk; -- 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-1.23 Makefile.PL patch
On 11/27/09, H.Merijn Brand h.m.br...@xs4all.nl wrote: On Fri, 27 Nov 2009 10:21:05 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: While you're at it, I'd like to see some more changes: * make /usr/share/oracle not hardcoded but variable We're running Oracle perl on a few Unix boxes without a /usr/share/oracle, so it seems it's not required in some cases. Our install is in /usr/oracle, and there's no oracle link in /usr/share. * make Instant Client work on windows too (Windows instant client works fine with the current Makefile.PL if installed on C:\Oracle\instantclient_11_1, but it does NOT work at all when installed in C:\Program Files\Oracle\... due to the space (I tried yesterday with the newest Strawberry) Sorry, I only do perl on Unix.
Re: DBD-Oracle-1.23 Makefile.PL patch
On Fri, 27 Nov 2009 10:41:19 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: On 11/27/09, H.Merijn Brand h.m.br...@xs4all.nl wrote: On Fri, 27 Nov 2009 10:21:05 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: While you're at it, I'd like to see some more changes: * make /usr/share/oracle not hardcoded but variable We're running Oracle perl on a few Unix boxes without a /usr/share/oracle, so it seems it's not required in some cases. Our install is in /usr/oracle, and there's no oracle link in /usr/share. There is a (huge) difference between a full Oracle install (server) or an Instant Client only. I prefer the latter if the box is to be client only, because it is much smaller. * make Instant Client work on windows too (Windows instant client works fine with the current Makefile.PL if installed on C:\Oracle\instantclient_11_1, but it does NOT work at all when installed in C:\Program Files\Oracle\... due to the space (I tried yesterday with the newest Strawberry) Sorry, I only do perl on Unix. So want I, but those silly customers ... That being said, I think Oracle on Windows is still easier than Oracle on AIX, which is even worse. That being said, Postgres is easier on *any* platform (and faster) than Oracle, but again, those silly customers ... -- 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-1.23 Makefile.PL patch
Of you could give it a try on 64 bit power solaris it you want to tug all of your hair out. H.Merijn Brand wrote: On Fri, 27 Nov 2009 10:41:19 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: On 11/27/09, H.Merijn Brand h.m.br...@xs4all.nl wrote: On Fri, 27 Nov 2009 10:21:05 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: While you're at it, I'd like to see some more changes: * make /usr/share/oracle not hardcoded but variable We're running Oracle perl on a few Unix boxes without a /usr/share/oracle, so it seems it's not required in some cases. Our install is in /usr/oracle, and there's no oracle link in /usr/share. There is a (huge) difference between a full Oracle install (server) or an Instant Client only. I prefer the latter if the box is to be client only, because it is much smaller. * make Instant Client work on windows too (Windows instant client works fine with the current Makefile.PL if installed on C:\Oracle\instantclient_11_1, but it does NOT work at all when installed in C:\Program Files\Oracle\... due to the space (I tried yesterday with the newest Strawberry) Sorry, I only do perl on Unix. So want I, but those silly customers ... That being said, I think Oracle on Windows is still easier than Oracle on AIX, which is even worse. That being said, Postgres is easier on *any* platform (and faster) than Oracle, but again, those silly customers ...
Re: DBD-Oracle-1.23 Makefile.PL patch
On Fri, 27 Nov 2009 10:17:01 -0500, John Scoles sco...@pythian.com wrote: Of you could give it a try on 64 bit power solaris it you want to tug all of your hair out. Would that be just as bad as True64? I feel your pain however. H.Merijn Brand wrote: On Fri, 27 Nov 2009 10:41:19 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: On 11/27/09, H.Merijn Brand h.m.br...@xs4all.nl wrote: On Fri, 27 Nov 2009 10:21:05 -0400, Ralph Doncaster ralphdoncas...@gmail.com wrote: While you're at it, I'd like to see some more changes: * make /usr/share/oracle not hardcoded but variable We're running Oracle perl on a few Unix boxes without a /usr/share/oracle, so it seems it's not required in some cases. Our install is in /usr/oracle, and there's no oracle link in /usr/share. There is a (huge) difference between a full Oracle install (server) or an Instant Client only. I prefer the latter if the box is to be client only, because it is much smaller. * make Instant Client work on windows too (Windows instant client works fine with the current Makefile.PL if installed on C:\Oracle\instantclient_11_1, but it does NOT work at all when installed in C:\Program Files\Oracle\... due to the space (I tried yesterday with the newest Strawberry) Sorry, I only do perl on Unix. So want I, but those silly customers ... That being said, I think Oracle on Windows is still easier than Oracle on AIX, which is even worse. That being said, Postgres is easier on *any* platform (and faster) than Oracle, but again, those silly customers ... -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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. A large warning in the upgreade notes should suffice for anyone transitioning. I'm undecided about the name of the attribute to indicate use of DBIstcf_DISCARD_PV. MinMemory or DiscardString or ...? I'm leaning more towards DiscardString = 1 as it directly describes what it does rather than a side-effect. +1 to DiscardString o I wouldn't mind someone else looking over the changes as although I currently maintain DBD::ODBC I do not consider myself a DBI internals of XS expert. Post a diff and I'll review it for you. The code you appended previously looks ok. Ditto. 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. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200911271301 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksQFFkACgkQvJuQZxSWSshf5wCgn8mSxnHM4YaUgn9P2wXaxqSe pvgAoIKvRQTZtxGKeJgs4dVzZAvCp1jg =nQJI -END PGP SIGNATURE-
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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. A large warning in the upgreade notes should suffice for anyone transitioning. I'm undecided about the name of the attribute to indicate use of DBIstcf_DISCARD_PV. MinMemory or DiscardString or ...? I'm leaning more towards DiscardString = 1 as it directly describes what it does rather than a side-effect. +1 to DiscardString o I wouldn't mind someone else looking over the changes as although I currently maintain DBD::ODBC I do not consider myself a DBI internals of XS expert. Post a diff and I'll review it for you. The code you appended previously looks ok. Ditto. 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. Greg, the issue I started by trying to address is rather specific to our use of JSON::XS and roughly described at http://rt.cpan.org/Public/Bug/Display.html?id=49818. The problem we faced is not specific to DBD::Oracle and applies to many DBDs (and certainly DBD::ODBC) although I believe it was addressed in Postgres a while ago. I don't think there is anything fundamentally wrong with what most DBDs do right now - Perl has always worked on the basis that you shouldn't need to know the way the underlaying data is stored, Perl will just do the right thing for the context you use the data. On the other hand we have the TYPE attribute to bind_col and no DBDs seems to do anything with it. While some may (and do) argue JSON::XS shouldn't do what it does I think the DBI side of this has moved on a bit now with these changes. Few, if any, DBDs pay any attention to the TYPE attribute on the bind_col method but /could/ benefit from knowing the type before the data is retrieved. For instance, DBD::ODBC (like may other DBDs) binds all the data from the database as strings but in many cases if you know the data is really an integer (or will be used as an integer) it is more efficient to retrieve it as such from the database. The TYPE argument to bind_col provides that information and these changes (if implemented in a DBD) simply arrange for the retrieved data to be cast to a Perl scalar with only the IV etc set and not the pv (assuming DiscardString is used). A big (pardon the pun) gain (other than the above) would be to support SQL_BIGINT. The database we are using is Oracle and it supports very large integers and as we know these will get (for primary keys etc) too big to fit in an integer or long integer we have to treat them as strings but they are not strings. Also, Oracle (and perhaps other databases) don't always like accepting strings for columns which are integers (they have to convert the strings and then sometimes decide that because of that they won't use an index on that column). I'd like to follow these changes up with some investigation for big integers and I'll hopefully find some time to do just that but one thing at a time. Martin
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.
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
I'm sorry for the delay in replying Martin.
On Tue, Nov 10, 2009 at 03:24:33PM +, Martin Evans wrote:
Perhaps it could have been one of those informationals as the sv is
unchanged and still usable but it is not in the requested format so
I'd class that an error.
Perhaps we should have $sth-bind_col(..., { LooselyTyped = 1 });
to allow for those who don't want an error if the type doesn't fit.
I'm happy with that.
That certainly feels better than overloading SQL_INTEGER vs SQL_NUMERIC
to achieve the same effect!
agreed.
We could make it default to issuing a warning on overflow, and have
attributes to specify either an error or ignore.
We could but I think most people would be happy with error or specifying
LooselyTyped. You either know you need LooselyTyped or not and if not
you can leave it off and if it errors then your data was not as you
thought and have to decide if your data is wrong or you need
LooselyTyped. I'd be concerned a warning might just get in the way.
I think a MinMemory attribute would be ok but I'd use it as in most of
my cases I am retrieving the whole result-set in one go and it can be
very large. How would post_fetch_sv know this attribute?
Via the flags argument.
As it turns out I /need/ MinMemory or SvPOKp(sv) returns true and that
ends up being a string again in JSON::XS.
After mulling it over some more, and looking at ODBC's SQLBindCol (which
takes a C type, not an SQL type) I've decided to err on the simple side.
I've appended a patch for review.
new patch snipped
There were a few small issues with the latest patch but it was obvious
what you meant so I have rectified them and made changes to my test
DBD::Oracle. This works rather nicely now.
At this stage I have the following changes and comments:
o patch as you supplied with minor corrections in DBI
) {
Safefree(SvPVX(sv));
SvPVX(sv) = Nullch; /* changed from NULL to Nullch */
SvLEN(sv) = 0; /* --- added this as it aborts without it */
SvPOK_off(sv);
}
Fixed. Thanks.
o added dbd_st_bind_col to DDB::Oracle
stores the requested type in fbh
handles LooselyTyped and MinMemory and saves in fbh
defaults to DBIstcf_STRICT if LooselyTyped not specified
Comment: I thought DBIstcf_STRICT was a good default but others may not.
Comment: I was not so keen on the attribute being LooselyTyped and the
macro being DBIstcf_STRICT as they have opposite meanings but I'm not
really bothered as LooselyTyped is all that is really going to be visible.
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.
Comment: DBIstcf_STRICT and DBIstcf_DISCARD_PV macros are not
available as symbols to a DBD at present so I'm using 1 and 2 in
DBD::Oracle. I wasn't sure where they'd go.
I've added them to DBIXS.h now.
I'm undecided about the name of the attribute to indicate use of
DBIstcf_DISCARD_PV. MinMemory or DiscardString or ...?
I'm leaning more towards DiscardString = 1 as it directly describes
what it does rather than a side-effect.
o oci8.c and dbd_st_fetch modified to call DBI's sql_type_cast_svpv and
errors when 0 (no strict conversion, with over/under flow converting
column N to type N) and -2 (sql type unhandled, with unsupported bind
type N for column N). I don't need to think about undef in
DBD::Oracle's case as it is handled separately.
Ok.
o test code using all this which demonstrates binding with a type works
and LoosleyTyped and MinMemory do as they should. Some of this will be a
little awkward to turn into a test that works for everyone as it needs
Devel::Peek.
Or JSON::XS :) Umm, or perhaps DBI::neat?
What I haven't done or would appreciate feedback on:
o My test DBD::Oracle currently assumes DBI has sql_type_cast_svpv. What
is the usual way of deciding this - checking DBI version?
I've bumped DBISTATE_VERSION from 94 to 95.
(Also DBIXS_REVISION 13590 would work.)
o any documentation for DBI::DBD although I am happy to do so when you
are happy we have reached a consensus.
Thank you!
o any documentation for DBI - as above.
Thank you!
o I wouldn't mind someone else looking over the changes as although I
currently maintain DBD::ODBC I do not consider myself a DBI internals of
XS expert.
Post a diff and I'll review it for you. The code you appended previously
looks ok.
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.
Great.
o I do not have a commit bit on DBD::Oracle so will pass the
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
Thread is getting a bit long so I've snipped a lot of previous code.
Tim Bunce wrote:
On Mon, Nov 09, 2009 at 05:05:11PM +, Martin Evans wrote:
Martin Evans wrote:
first patch snipped
There was an omission in my addition to Tim's example as I forgot to
change DBISTATE_VERSION.
Thanks. Though that's less important than it was now there's also
DBIXS_REVISION (in dbixs_rev.h) that automatically tracks the svn
revsion number.
I've implemented this as it stands in DBD::Oracle and it seems to work
out ok and certainly where I was wanting to go (and further).
Ok.
My own feeling is that if someone asks for something to be bound as an
SQL_INTEGER and it cannot due to over/under flow this should be an error
and that is how I've implemented it.
The return value of post_fetch_sv() is meant to allow drivers to
report an error.
I thought about making post_fetch_sv() itself call DBIh_SET_ERR_* to
report an error but opted to avoid that because, to generate a good
error more info would need to be passed, like the column number.
I agree and had already output an error containing the column number.
On the other hand, if post_fetch_sv() doesn't do it then there's a
greater risk of inconsistency between the drivers.
I think we already have a level of inconsistency as some drivers already
return IVs without being asked for them. Also, number handling in each
database tends to differ quite a bit so I suspect the default may want
to differ per DBD.
Perhaps it could have been one of those informationals as the sv is
unchanged and still usable but it is not in the requested format so
I'd class that an error.
Perhaps we should have $sth-bind_col(..., { LooselyTyped = 1 });
to allow for those who don't want an error if the type doesn't fit.
I'm happy with that.
That certainly feels better than overloading SQL_INTEGER vs SQL_NUMERIC
to achieve the same effect!
agreed.
However, I have
a very small concern for people who might have been binding columns with
a type but no destination SV but their DBD did nothing about it (which I
believe is all DBDs up to now). For me, I didn't leave that code in and
just documented it as:
# I was hoping the following would work (according to DBI, it
# might) to ensure the a, b and c
# columns are returned as integers instead of strings saving
# us from having to add 0 to them below. It does not with
# DBD::Oracle.
# NOTE: you don't have to pass a var into bind_col to receive
# the column data as it works on the underlying column and not
# just a particular bound variable.
#$cursor-bind_col(4, undef, { TYPE = SQL_INTEGER });
#$cursor-bind_col(5, undef, { TYPE = SQL_INTEGER });
#$cursor-bind_col(10, undef, { TYPE = SQL_INTEGER });
but if those last 3 lines were left uncommented they would have ended up
a noop before but not now. However, I'd be surprised if anyone was
really doing that as it did nothing.
Does anyone know of any drivers that pay any attention to the type param
of bind_column?
I did not find one when I was looking a few months ago.
We could make it default to issuing a warning on overflow, and have
attributes to specify either an error or ignore.
We could but I think most people would be happy with error or specifying
LooselyTyped. You either know you need LooselyTyped or not and if not
you can leave it off and if it errors then your data was not as you
thought and have to decide if your data is wrong or you need
LooselyTyped. I'd be concerned a warning might just get in the way.
I think a MinMemory attribute would be ok but I'd use it as in most of
my cases I am retrieving the whole result-set in one go and it can be
very large. How would post_fetch_sv know this attribute?
Via the flags argument.
As it turns out I /need/ MinMemory or SvPOKp(sv) returns true and that
ends up being a string again in JSON::XS. i.e., I needed the equivalent
of adding 0 to the sv which does this:
perl -le 'use Devel::Peek;my $a = 5; Dump($a); $a = $a + 0; Dump($a);'
SV = PV(0x8154b00) at 0x815469c
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x816fb48 5\0
CUR = 1
LEN = 4
SV = PVIV(0x8155b10) at 0x815469c
REFCNT = 1
FLAGS = (PADBUSY,PADMY,IOK,pIOK)
IV = 5
PV = 0x816fb48 5\0
CUR = 1
LEN = 4
as JSON::XS does:
if (SvPOKp (sv))
{
.
}
else if (SvNOKp (sv))
{
.
}
else if (SvIOKp (sv))
{
I want this case.
Of course, I could argue with the JSON::XS maintainer for changing the
order but I don't hold out much hope of that changing.
What was the intention of void *v argument at the end of post_fetch_sv?
Planning for an uncertain future.
ok.
After mulling it over some more, and looking at ODBC's SQLBindCol (which
takes a C type, not an SQL type) I've decided to err on the simple side.
I've appended a patch for review.
Tim.
new patch snipped
There were a few small issues with the latest patch but it was obvious
what you meant so I have rectified them and made
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
Tim Bunce wrote:
On Tue, Oct 27, 2009 at 02:54:43PM +, Martin Evans wrote:
The next question is whether overflowing to an NV should be an error.
I'm thinking we could adopt these semantics for bind_col types:
SQL_INTEGER IV or UV via sv_2iv(sv) with error on overflow
this would be ideal.
SQL_DOUBLE NV via sv_2nv(sv)
SQL_NUMERIC IV else UV else NV via grok_number() with no error
I could sketch out the logic for those cases if you'd be happy to polish
up and test.
I would be happy to do that.
I finally got around to working on this. Here's a first rough draft
(which a bunch of issues) I thought I'd post here for discussion.
I've implemented it as a hook in the DBIS structure so drivers can call
it directly.
I've added the idea of optionally discarding the string buffer (which
would save space when storing many rows but waste time if just working
row-at-a-time). For now I've triggered that based on the sql_type but
that feels like a hack we'd regret later. A better approach might be an
attribute to bind_col:
$sth-bind_col(..., { MinMemory = 1 });
$sth-fetchall_...();
This code doesn't raise any errors or produce any warnings (directly),
it just returns a status that the driver should check if it wants to
implement the SQL_INTEGER == error on overflow semantics, which it
should if we agree that's what we're going to adopt.
Tim.
Index: DBI.xs
===
--- DBI.xs(revision 13466)
+++ DBI.xs(working copy)
@@ -78,6 +78,7 @@
static int set_err_char _((SV *h, imp_xxh_t *imp_xxh, const char
*err_c, IV err_i, const char *errstr, const char *state, const char *method));
static int set_err_sv _((SV *h, imp_xxh_t *imp_xxh, SV *err, SV
*errstr, SV *state, SV *method));
static int quote_type _((int sql_type, int p, int s, int *base_type,
void *v));
+static int post_fetch_sv _((pTHX_ SV *h, imp_xxh_t *imp_xxh, SV *sv,
int sql_type, U32 flags, void *v));
static I32 dbi_hash _((const char *string, long i));
static void dbih_dumphandle _((pTHX_ SV *h, const char *msg, int level));
static int dbih_dumpcom _((pTHX_ imp_xxh_t *imp_xxh, const char *msg,
int level));
@@ -439,6 +440,7 @@
DBIS-set_err_sv = set_err_sv;
DBIS-set_err_char= set_err_char;
DBIS-bind_col= dbih_sth_bind_col;
+DBIS-post_fetch_sv = post_fetch_sv;
/* Remember the last handle used. BEWARE! Sneaky stuff here!*/
@@ -1714,6 +1718,94 @@
}
+/* Convert a simple string representation of a value into a more specific
+ * perl type based on an sql_type value.
+ * The semantics of SQL standard TYPE values are interpreted _very_ loosely
+ * on the basis of be liberal in what you accept and let's throw in some
+ * extra semantics while we're here :)
+ * Returns:
+ * -1: sv is undef or doesn't
+ * 0: sv couldn't be converted to requested (strict) type
+ * 1: sv was handled without a problem
+ */
+int
+post_fetch_sv(pTHX_ SV *h, imp_xxh_t *imp_xxh, SV *sv, int sql_type, U32
flags, void *v)
+{
+int discard_pv = 0;
+
+/* do nothing for undef (NULL) or non-string values */
+if (!sv || !SvPOK(sv))
+return -1;
+
+switch(sql_type) {
+
+/* caller would like IV (but may get UV or NV) */
+/* will warn if not numeric. return 0 on overflow */
+case SQL_SMALLINT:
+discard_pv = 1;
+case SQL_INTEGER:
+sv_2iv(sv); /* is liberal, may return SvIV, SvUV, or SvNV */
+if (SvNOK(sv)) { /* suspicious */
+NV nv = SvNV(sv);
+/* ignore NV set just to preserve digits after the decimal place
*/
+/* just complain if the value won't fit in an IV or NV */
+if (nv UV_MAX || nv IV_MIN)
+return 0;
+}
+break;
+
+/* caller would like SvNOK/SvIOK true if the value is a number */
+/* will warn if not numeric */
+case SQL_FLOAT:
+discard_pv = 1;
+case SQL_DOUBLE:
+sv_2nv(sv);
+break;
+
+/* caller would like IV else UV else NV */
+/* else no error and sv is untouched */
+case SQL_NUMERIC:
+discard_pv = 1;
+case SQL_DECIMAL: {
+UV uv;
+/* based on the code in perl's toke.c */
+int flags = grok_number(SvPVX(sv), SvCUR(sv), uv);
+
+if (flags == IS_NUMBER_IN_UV) { /* +ve int */
+if (uv = IV_MAX) /* prefer IV over UV */
+ sv_2iv(sv);
+else sv_2uv(sv);
+}
+else if (flags == (IS_NUMBER_IN_UV | IS_NUMBER_NEG)
+ uv = IV_MAX
+) {
+sv_2iv(sv);
+}
+else if (flags) /* is numeric */
+sv_2nv(sv);
+}
+break;
+
+#if 0 /* XXX future possibilities */
+case SQL_BIGINT:/* use Math::BigInt if too large for IV/UV */
+#endif
+
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
On Mon, Nov 09, 2009 at 02:43:28PM +, Martin Evans wrote: I'm presuming you missed a bit off your patch: Yes, sorry, I was just throwing it out there for discussion of the general approach/principles. None so far. Tim.
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
On Mon, Nov 09, 2009 at 05:05:11PM +, Martin Evans wrote:
Martin Evans wrote:
+/* Convert a simple string representation of a value into a more specific
+ * perl type based on an sql_type value.
+ * The semantics of SQL standard TYPE values are interpreted _very_
loosely
+ * on the basis of be liberal in what you accept and let's throw in some
+ * extra semantics while we're here :)
+ * Returns:
+ * -1: sv is undef or doesn't
+ * 0: sv couldn't be converted to requested (strict) type
+ * 1: sv was handled without a problem
+ */
+int
+post_fetch_sv(pTHX_ SV *h, imp_xxh_t *imp_xxh, SV *sv, int sql_type, U32
flags, void *v)
+{
+int discard_pv = 0;
+
+/* do nothing for undef (NULL) or non-string values */
+if (!sv || !SvPOK(sv))
+return -1;
+
+switch(sql_type) {
+
+/* caller would like IV (but may get UV or NV) */
+/* will warn if not numeric. return 0 on overflow */
+case SQL_SMALLINT:
+discard_pv = 1;
+case SQL_INTEGER:
+sv_2iv(sv); /* is liberal, may return SvIV, SvUV, or SvNV */
+if (SvNOK(sv)) { /* suspicious */
+NV nv = SvNV(sv);
+/* ignore NV set just to preserve digits after the decimal
place */
+/* just complain if the value won't fit in an IV or NV */
+if (nv UV_MAX || nv IV_MIN)
+return 0;
+}
+break;
+
+/* caller would like SvNOK/SvIOK true if the value is a number */
+/* will warn if not numeric */
+case SQL_FLOAT:
+discard_pv = 1;
+case SQL_DOUBLE:
+sv_2nv(sv);
+break;
+
+/* caller would like IV else UV else NV */
+/* else no error and sv is untouched */
+case SQL_NUMERIC:
+discard_pv = 1;
+case SQL_DECIMAL: {
+UV uv;
+/* based on the code in perl's toke.c */
+int flags = grok_number(SvPVX(sv), SvCUR(sv), uv);
+
+if (flags == IS_NUMBER_IN_UV) { /* +ve int */
+if (uv = IV_MAX) /* prefer IV over UV */
+ sv_2iv(sv);
+else sv_2uv(sv);
+}
+else if (flags == (IS_NUMBER_IN_UV | IS_NUMBER_NEG)
+ uv = IV_MAX
+) {
+sv_2iv(sv);
+}
+else if (flags) /* is numeric */
+sv_2nv(sv);
+}
+break;
+
+#if 0 /* XXX future possibilities */
+case SQL_BIGINT:/* use Math::BigInt if too large for IV/UV */
+#endif
+default:
+return 0; /* value unchanged */
+}
+
+if (discard_pv/* caller wants string buffer discarded */
+ SvNIOK(sv) /* we set a numeric value */
+ SvPVX(sv) SvLEN(sv) /* we have a buffer to discard */
+) {
+Safefree(SvPVX(sv));
+SvPVX(sv) = NULL;
+SvPOK_off(sv);
+}
+return 1;
+}
There was an omission in my addition to Tim's example as I forgot to
change DBISTATE_VERSION.
Thanks. Though that's less important than it was now there's also
DBIXS_REVISION (in dbixs_rev.h) that automatically tracks the svn
revsion number.
I've implemented this as it stands in DBD::Oracle and it seems to work
out ok and certainly where I was wanting to go (and further).
Ok.
My own feeling is that if someone asks for something to be bound as an
SQL_INTEGER and it cannot due to over/under flow this should be an error
and that is how I've implemented it.
The return value of post_fetch_sv() is meant to allow drivers to
report an error.
I thought about making post_fetch_sv() itself call DBIh_SET_ERR_* to
report an error but opted to avoid that because, to generate a good
error more info would need to be passed, like the column number.
On the other hand, if post_fetch_sv() doesn't do it then there's a
greater risk of inconsistency between the drivers.
Perhaps it could have been one of those informationals as the sv is
unchanged and still usable but it is not in the requested format so
I'd class that an error.
Perhaps we should have $sth-bind_col(..., { LooselyTyped = 1 });
to allow for those who don't want an error if the type doesn't fit.
That certainly feels better than overloading SQL_INTEGER vs SQL_NUMERIC
to achieve the same effect!
However, I have
a very small concern for people who might have been binding columns with
a type but no destination SV but their DBD did nothing about it (which I
believe is all DBDs up to now). For me, I didn't leave that code in and
just documented it as:
# I was hoping the following would work (according to DBI, it
# might) to ensure the a, b and c
# columns are returned as integers instead of strings saving
# us from having to add 0 to them below. It does not with
# DBD::Oracle.
# NOTE: you don't have to pass a var into bind_col to receive
# the column data as it works on the underlying column and not
#
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I cannot say why you changed DBD::Pg for JSON::XS but I can say why I want integers back from Oracle instead of strings when I ask for integers and the column is an integer. I don't think it is square pegs into round holes. Well you'll never get a Perl integer (IV) to match Oracle's integer: NUMBER(38). But sounds like y'all have found a good enough solution. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200910281253 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkrodzUACgkQvJuQZxSWSsjR7QCeKbkwnKKZK7zgC0laJ3sozeoh JccAnA8puFN+uX7ieOSzf924LJuj72qw =yYAY -END PGP SIGNATURE-
