RE: Problem with Oracle ODBC connection
If sqlplus DOES return data: What version of Oracle ODBC and Oracle client are you using, and what version is oracle on the far end? hm, how can I find out the client version? I see nothing in the ODBC connection about the version, but when I click the Help Button, I get the help for version 10.1.0.2.0. On the Server it should be 10.1, too. We have installed three client versions on our standard Desktops, 8/9/10, but there is no ORACLE_HOME set as I know it from earlier days. So how is defined which client the ODBC connection uses? Lars
RE: Problem with Oracle ODBC connection
All we can say now is that you successfully issue a query on a table and it returns now rows. ok, I have to apologize for my dumbness and stealing your time... I'm not used to oracle and to have to commit... With the PostgreSQL's I usually work with we have Autocommit running, but not on that oracle. I just missed to commit the data to the table ;) Lars
[Fwd: [ANNOUNCE] == Postgres Weekly News - April 01 2009 ==]
This is not Perl specific, but probably something any current or possible users of Postgres should know as they plan their futures. -- Darren Duncan Original Message Subject: [ANNOUNCE] == Postgres Weekly News - April 01 2009 == Date: Wed, 1 Apr 2009 01:44:32 -0700 From: David Fetter da...@fetter.org To: PostgreSQL Announce pgsql-annou...@postgresql.org == Postgres Weekly News - April 01 2009 == Following MySQL's lead as usual, the PostgreSQL project is dividing into several lines of development: - Shizzle: High-performance and Feature-Free - MaryMary: Compiled with libhaltingproblem - Narcona: Painless installation and setup - OurThing: Lots of sources, based in Sicily - XPostgres: Everybody who's ever worked on Postgres code, back to UC Berkeley and Illustra. - Moon/PostgreSQL: Corporate support, as long as it lasts. The PostgreSQL Global Development Group will be shutting down the mailing lists as of today. Future communication for the project will be through Twitter, the bug tracker, and the Bitkeeper source code management system.
Oracle VARRAY support
Still dbi::Oracle does not support Oracle varray types. Any plans to implement this ? Or does anybody know another perl connector module that supports this type ? We still only can use the java jdbc connectors which have support for that odd speciality. -- Dr. Udo Grabowski email: udo.grabow...@imk.fzk.de Institut f. Meteorologie und Klimaforschung ASF,Forschungszentrum Karlsruhe Postfach 3640, 76021 Karlsruhe, Germany Tel: (+49) 7247 82-6026 http://www.fzk.de/imk/asf/sat/grabowski/Fax: -7026
Re: Oracle VARRAY support
Actually it does support varray types since 1.20 (at least for select) http://search.cpan.org/~pythian/DBD-Oracle-1.22/Oracle.pm#Object__Collection_Data_Types You can select them all you want. I have not yet added support for inserts and updates and that is handled by psql better than the hay that DBI with DBD::Oracle would do it In the trunk version of DBD::Oracle it can also load the Varray into Perl object rather than an ref array Udo Grabowski wrote: Still dbi::Oracle does not support Oracle varray types. Any plans to implement this ? Or does anybody know another perl connector module that supports this type ? We still only can use the java jdbc connectors which have support for that odd speciality.
5.8.9 eating up memory with AUTOLOAD
Hello,
I'm having a strange problem. I compiled 5.8.9 on SUSE Linux Enterprise
Server 10 (x86_64),
installed DBI DBD::Oracle. We are running Oracle 11g on this server.
Running a program that
uses DBI/DBD::Oracle, the process locked the server up by using all the memory
and swap. The server
has 32 gig of memory and I believe 16 gig of swap. Running in the debugger, I
isolated the problem in
DBD/Oracle.pm,
my $oci = DBD::Oracle::ORA_OCI();
sub AUTOLOAD {
(my $constname = $AUTOLOAD) =~ s/.*:://;
my $val = constant($constname);
*$AUTOLOAD = sub { $val };
goto $AUTOLOAD;
}
AUTOLOAD loads DBD::Oracle::ORA_OCI, which triggers the loading of
DBD::Oracle::constant.
DBD::Oracle::constant is not found, so constant is loaded, not found, constant
loadedetc
I checked Oracle.so (just in case for some crazy reason constant didn't get in
the so) it's
there. What perplexes me is this perl install is the just like several other
servers we have.
The one big difference is there is an 11g Oracle server running on this box. I
have the same
set up on an open-SuSE box that works fine, but it is only using the 11g
client. The only problems
I had when compiling DBD::Oracle was the lob-plsql test failing, otherwise
everything worked fine.
I don't even know if Oracle is the issue here. Should I post to P5P?
Thanks
Scott
Summary of my perl5 (revision 5 version 8 subversion 9) configuration:
Platform:
osname=linux, osvers=2.6.27.19, archname=x86_64-linux
uname='linux srv12 2.6.27.19 #1 smp mon feb 23 16:46:24 cst 2009 x86_64
x86_64 x86_64 gnulinux '
config_args='-de -Dprefix=/usr/local/perl-5.8.9 -Dnoextensions=ODBM_File
-Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Dldflags=-L/usr/local/lib64
-Duse64bitall=define'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='4.1.2 20070115 (SUSE Linux)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.4.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT
USE_FAST_STDIO USE_LARGE_FILES USE_PERLIO
Built under linux
Compiled at Mar 31 2009 10:07:10
%ENV:
PERL5LIB=/usr/local/lib/tools/perlmodules
@INC:
/usr/local/lib/tools/perlmodules
/usr/local/perl-5.8.9/lib/5.8.9/x86_64-linux
/usr/local/perl-5.8.9/lib/5.8.9
/usr/local/perl-5.8.9/lib/site_perl/5.8.9/x86_64-linux
/usr/local/perl-5.8.9/lib/site_perl/5.8.9
.
Re: DBD::Oracle problem with bind_param_inout and UTF-8
Hi John,
Did you make any sense of this?
Thanks,
Steve
On 30/03/2009, at 10:39 AM, Steve Baldwin wrote:
John,
In case it helps, here is a version of my test script that seems to
correctly handle utf-8 chars for bind_param_inout ...
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI qw();
use DBD::Oracle qw();
use Encode;
print Using DBI $DBI::VERSION and DBD::Oracle $DBD::Oracle::VERSION
\n;
my $uidpwd = 'usr/p...@db';
my $dbh = DBI-connect(
'dbi:Oracle:',
$uidpwd,
'',
{RaiseError = 1, PrintError = 0});
my $sth = $dbh-prepare(q(
select chr(14844588)
fromdual
));
$sth-execute;
my ($sym1, $sym2, $sym3);
$sth-bind_columns(\($sym1));
$sth-fetch;
print Sym (1) = $sym1\n;
$sth = $dbh-prepare(q(
BEGIN
:ret := chr(14844588);
END;
));
$sth-bind_param_inout(':ret', \$sym2, 10);
$sth-execute;
print Sym (2 before) = $sym2\n;
Encode::_utf8_on($sym2);
unless (Encode::is_utf8($sym2, 1)) {
Encode::_utf8_off($sym2);
$sym2 = Encode::encode('UTF-8', $sym2);
}
print Sym (2 after) = $sym2\n;
$dbh-disconnect;
stbald...@au-stb-mobile:~/dev$ ./utf8.plx
Using DBI 1.605 and DBD::Oracle 1.23
Sym (1) = €
Sym (2 before) = â¬
Sym (2 after) = €
So, we have a workaround of sorts, but I'd rather not go through all
our
code and add the manual encoding stuff.
Thanks for your help,
Steve
On Sun, 2009-03-29 at 12:17 +1100, Steve Baldwin wrote:
John,
I installed this version and it didn't seem to make any
difference ...
stbald...@au-stb-mobile:~/dev$ ./utf8.plx
Using DBI 1.605 and DBD::Oracle 1.23
Sym (1) = €
Sym (2) = €
I see the same behaviour whether I connect to an 11g or 9i
database. I
have the 11g oracle client.
Here's a level 3 trace ...
- prepare for DBD::Oracle::db
(DBI::db=HASH(0x82ece1c)~0x82ecdb0 '
select chr(14844588)
fromdual
') thr#8153008
dbd_st_prepare'd sql SELECT (pl1, auto_lob1, check_sql1)
dbd_describe SELECT (EXPLICIT, lb 80)...
Described col 1: dbtype 1(VARCHAR), scale 0, prec 3, nullok 1, name
CHR(14844588)
: dbsize 3, char_used 1, char_size 1, csid 873, csform 1,
disize 3
fbh 1: 'CHR(14844588)' NULLable, otype 1- 5, dbsize 3/4, p3.s0
row cache OCI_ATTR_PREFETCH_ROWS 1042, OCI_ATTR_PREFETCH_MEMORY 0
rs_array_init: rs_array_on=0, rs_array_size=1
calling OCIAttrSet OCI_ATTR_CHARSET_FORM with csform=1
dbd_describe'd 1 columns (row bytes: 3 max, 1 est avg, cache: 1042)
- prepare= DBI::st=HASH(0x82ecf78) at utf8.plx line 13
- execute for DBD::Oracle::st (DBI::st=HASH(0x82ecf78)~0x82eceac)
thr#8153008
dbd_st_execute SELECT (out0, lob0)...
Statement Execute Mode is 0 (DEFAULT)
dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)
- execute= '0E0' at utf8.plx line 17
- bind_columns in DBD::_::st for DBD::Oracle::st
(DBI::st=HASH(0x82ecf78)~0x82eceac SCALAR(0x81ff2bc)) thr#8153008
.. FETCH DBI::st=HASH(0x82eceac) 'NUM_OF_FIELDS' = 1 (cached)
1 - FETCH= 1 at DBI.pm line 1828 via at utf8.plx line 19
1 - bind_col= 1 at DBI.pm line 1839 via at utf8.plx line 19
- bind_columns= 1 at utf8.plx line 19
- fetch for DBD::Oracle::st (DBI::st=HASH(0x82ecf78)~0x82eceac)
thr#8153008
dbd_st_fetch 1 fields...
dbd_st_fetched 1 fields with status of 0(SUCCESS)
- fetch= [ € ] row1 at utf8.plx line 20
Sym (1) = €
- prepare for DBD::Oracle::db
(DBI::db=HASH(0x82ece1c)~0x82ecdb0 '
BEGIN
:ret := chr(14844588);
END;
') thr#8153008
dbd_preparse scanned 1 distinct placeholders
dbd_st_prepare'd sql BEGIN (pl1, auto_lob1, check_sql1)
dbd_describe skipped for BEGIN
- prepare= DBI::st=HASH(0x824973c) at utf8.plx line 22
DESTROY(DBI::st=HASH(0x82ecf78)) ignored for outer handle
(inner
DBI::st=HASH(0x82eceac) has ref cnt 1)
- DESTROY for DBD::Oracle::st (DBI::st=HASH(0x82eceac)~INNER)
thr#8153008
- DESTROY= undef at utf8.plx line 27 via at utf8.plx line 27
- bind_param_inout for DBD::Oracle::st
(DBI::st=HASH(0x824973c)~0x82ed05c ':ret' SCALAR(0x81ff2ec) 10)
thr#8153008
dbd_bind_ph(): bind :ret == undef (type 0 (DEFAULT (varchar)), inout
0x81ff2ec, maxlen 10)
dbd_rebind_ph_char() (1): bind :ret == undef (NULL, size 0/0/10,
ptype
4(VARCHAR), otype 1 , inout)
dbd_rebind_ph_char() (2): bind :ret == '' (size 0/32, otype
1(VARCHAR),
indp -1, at_exec 1)
bind :ret as ftype 1 (VARCHAR)
dbd_rebind_ph(): bind :ret == undef (inout, not-utf8, csid 873-0-
873,
ftype 1 (VARCHAR), csform 0-0, maxlen 32, maxdata_size 0)
- bind_param_inout= 1 at utf8.plx line 27
- execute for DBD::Oracle::st (DBI::st=HASH(0x824973c)~0x82ed05c)
thr#8153008
dbd_st_execute BEGIN (out1, lob0)...
with :ret = '' (len 0(0)/32, indp -1, otype 1, ptype 6)
Statement Execute Mode is 32 (COMMIT_ON_SUCCESS)
in ':ret' [0,0]: len 0, ind -1, value=undef
out ':ret' [0,0]: alen 36, piece 0
dbd_st_execute BEGIN returned (SUCCESS, rpc1, fn34, out1)
Re: 5.8.9 eating up memory with AUTOLOAD in DBD::Oracle
Wanted to change the subject.
On Wed, 2009-04-01 at 11:11 -0500, Scott T. Hildreth wrote:
Hello,
I'm having a strange problem. I compiled 5.8.9 on SUSE Linux Enterprise
Server 10 (x86_64),
installed DBI DBD::Oracle. We are running Oracle 11g on this server.
Running a program that
uses DBI/DBD::Oracle, the process locked the server up by using all the
memory and swap. The server
has 32 gig of memory and I believe 16 gig of swap. Running in the debugger,
I isolated the problem in
DBD/Oracle.pm,
my $oci = DBD::Oracle::ORA_OCI();
sub AUTOLOAD {
(my $constname = $AUTOLOAD) =~ s/.*:://;
my $val = constant($constname);
*$AUTOLOAD = sub { $val };
goto $AUTOLOAD;
}
AUTOLOAD loads DBD::Oracle::ORA_OCI, which triggers the loading of
DBD::Oracle::constant.
DBD::Oracle::constant is not found, so constant is loaded, not found,
constant loadedetc
I checked Oracle.so (just in case for some crazy reason constant didn't get
in the so) it's
there. What perplexes me is this perl install is the just like several other
servers we have.
The one big difference is there is an 11g Oracle server running on this box.
I have the same
set up on an open-SuSE box that works fine, but it is only using the 11g
client. The only problems
I had when compiling DBD::Oracle was the lob-plsql test failing, otherwise
everything worked fine.
I don't even know if Oracle is the issue here. Should I post to P5P?
Thanks
Scott
Summary of my perl5 (revision 5 version 8 subversion 9) configuration:
Platform:
osname=linux, osvers=2.6.27.19, archname=x86_64-linux
uname='linux srv12 2.6.27.19 #1 smp mon feb 23 16:46:24 cst 2009 x86_64
x86_64 x86_64 gnulinux '
config_args='-de -Dprefix=/usr/local/perl-5.8.9 -Dnoextensions=ODBM_File
-Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Dldflags=-L/usr/local/lib64
-Duse64bitall=define'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='4.1.2 20070115 (SUSE Linux)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.4.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT
USE_FAST_STDIO USE_LARGE_FILES USE_PERLIO
Built under linux
Compiled at Mar 31 2009 10:07:10
%ENV:
PERL5LIB=/usr/local/lib/tools/perlmodules
@INC:
/usr/local/lib/tools/perlmodules
/usr/local/perl-5.8.9/lib/5.8.9/x86_64-linux
/usr/local/perl-5.8.9/lib/5.8.9
/usr/local/perl-5.8.9/lib/site_perl/5.8.9/x86_64-linux
/usr/local/perl-5.8.9/lib/site_perl/5.8.9
.
Re: 5.8.9 eating up memory with AUTOLOAD in DBD::Oracle
On Wed, 2009-04-01 at 12:54 -0500, Scott T. Hildreth wrote:
Wanted to change the subject.
On Wed, 2009-04-01 at 11:11 -0500, Scott T. Hildreth wrote:
Hello,
I'm having a strange problem. I compiled 5.8.9 on SUSE Linux
Enterprise Server 10 (x86_64),
installed DBI DBD::Oracle. We are running Oracle 11g on this server.
Running a program that
uses DBI/DBD::Oracle, the process locked the server up by using all the
memory and swap. The server
has 32 gig of memory and I believe 16 gig of swap. Running in the
debugger, I isolated the problem in
DBD/Oracle.pm,
So, I asked our Dba to install the 10g client for me. I recompiled
DBD::Oracle using the 10g client. Ran the same code and wa la. I
really am not liking the 11g client libraries.
my $oci = DBD::Oracle::ORA_OCI();
sub AUTOLOAD {
(my $constname = $AUTOLOAD) =~ s/.*:://;
my $val = constant($constname);
*$AUTOLOAD = sub { $val };
goto $AUTOLOAD;
}
AUTOLOAD loads DBD::Oracle::ORA_OCI, which triggers the loading of
DBD::Oracle::constant.
DBD::Oracle::constant is not found, so constant is loaded, not found,
constant loadedetc
I checked Oracle.so (just in case for some crazy reason constant didn't get
in the so) it's
there. What perplexes me is this perl install is the just like several
other servers we have.
The one big difference is there is an 11g Oracle server running on this
box. I have the same
set up on an open-SuSE box that works fine, but it is only using the 11g
client. The only problems
I had when compiling DBD::Oracle was the lob-plsql test failing, otherwise
everything worked fine.
I don't even know if Oracle is the issue here. Should I post to P5P?
Thanks
Scott
Summary of my perl5 (revision 5 version 8 subversion 9) configuration:
Platform:
osname=linux, osvers=2.6.27.19, archname=x86_64-linux
uname='linux srv12 2.6.27.19 #1 smp mon feb 23 16:46:24 cst 2009
x86_64 x86_64 x86_64 gnulinux '
config_args='-de -Dprefix=/usr/local/perl-5.8.9
-Dnoextensions=ODBM_File -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64
-Dldflags=-L/usr/local/lib64 -Duse64bitall=define'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='4.1.2 20070115 (SUSE Linux)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.4.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT
USE_FAST_STDIO USE_LARGE_FILES USE_PERLIO
Built under linux
Compiled at Mar 31 2009 10:07:10
%ENV:
PERL5LIB=/usr/local/lib/tools/perlmodules
@INC:
/usr/local/lib/tools/perlmodules
/usr/local/perl-5.8.9/lib/5.8.9/x86_64-linux
/usr/local/perl-5.8.9/lib/5.8.9
/usr/local/perl-5.8.9/lib/site_perl/5.8.9/x86_64-linux
/usr/local/perl-5.8.9/lib/site_perl/5.8.9
.
Building DBD::Oracle on OS/X Leopard
I'm attempting to build DBD::Oracle for the first time on a Mac. Not much luck so far. I'm attempting to build using the latest Instant Client. Here's what happens ... stbaldwins-macbook-pro:DBD-Oracle-1.22-DQ1QKH root# perl Makefile.PL Using DBI 1.52 (for perl 5.008008 on darwin-thread-multi-2level) installed in /System/Library/Perl/Extras/5.8.8/darwin-thread- multi-2level/auto/DBI/ Configuring DBD::Oracle for perl 5.008008 on darwin (darwin-thread- multi-2level) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a darwin, Ver#9.0 Using Oracle in /var/oracle/instantclient_10_2 DEFINE _SQLPLUS_RELEASE = 1002000400 (CHAR) Oracle version 10.2.0.4 (10.2) Looks like an Instant Client installation, okay Your DYLD_LIBRARY_PATH env var is set to '/var/oracle/ instantclient_10_2:' Oracle sysliblist: Found header files in /var/oracle/instantclient_10_2/sdk/include. Checking for functioning wait.ph System: perl5.008008 darwin b04.apple.com 9.0 darwin kernel version 9.3.0: tue aug 12 17:18:07 pdt 2008; root:xnu-1228.5.90~13release_i386 i386 Compiler: cc -O3 -arch i386 -arch ppc -g -pipe -fno-common - DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -Wdeclaration-after- statement -I/usr/local/include Linker: /usr/bin/ld Sysliblist: Linking with -lclntsh. Checking if your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. LD_RUN_PATH=/var/oracle/instantclient_10_2 Using DBD::Oracle 1.22. Using DBD::Oracle 1.22. Using DBI 1.52 (for perl 5.008008 on darwin-thread-multi-2level) installed in /System/Library/Perl/Extras/5.8.8/darwin-thread- multi-2level/auto/DBI/ Writing Makefile for DBD::Oracle *** 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?) stbaldwins-macbook-pro:DBD-Oracle-1.22-DQ1QKH root# make cp Oracle.pm blib/lib/DBD/Oracle.pm cp oraperl.ph blib/lib/oraperl.ph cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h cp Oraperl.pm blib/lib/Oraperl.pm cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm /usr/bin/perl -p -e s/~DRIVER~/Oracle/g /System/Library/Perl/Extras/ 5.8.8/darwin-thread-multi-2level/auto/DBI/Driver.xst Oracle.xsi /usr/bin/perl /System/Library/Perl/5.8.8/ExtUtils/xsubpp -typemap / System/Library/Perl/5.8.8/ExtUtils/typemap -typemap typemap Oracle.xs Oracle.xsc mv Oracle.xsc Oracle.c cc -c -I/var/oracle/instantclient_10_2/sdk/include -I/System/Library/ Perl/Extras/5.8.8/darwin-thread-multi-2level/auto/DBI -arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict- aliasing -Wdeclaration-after-statement -I/usr/local/include -O3 - DVERSION=\1.22\ -DXS_VERSION=\1.22\ -I/System/Library/Perl/5.8.8/ darwin-thread-multi-2level/CORE -Wall -Wno-comment -DUTF8_SUPPORT - DNEW_OCI_INIT -DORA_OCI_VERSION=\10.2.0.4\ Oracle.c cc -c -I/var/oracle/instantclient_10_2/sdk/include -I/System/Library/ Perl/Extras/5.8.8/darwin-thread-multi-2level/auto/DBI -arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict- aliasing -Wdeclaration-after-statement -I/usr/local/include -O3 - DVERSION=\1.22\ -DXS_VERSION=\1.22\ -I/System/Library/Perl/5.8.8/ darwin-thread-multi-2level/CORE -Wall -Wno-comment -DUTF8_SUPPORT - DNEW_OCI_INIT -DORA_OCI_VERSION=\10.2.0.4\ dbdimp.c dbdimp.c: In function ‘createxmlfromstring’: dbdimp.c:1077: warning: passing argument 4 of ‘OCILobWriteAppend’ from incompatible pointer type dbdimp.c: In function ‘createxmlfromstring’: dbdimp.c:1077: warning: passing argument 4 of ‘OCILobWriteAppend’ from incompatible pointer type dbdimp.c: In function ‘ora_st_execute_array’: dbdimp.c:3328: warning: unused variable ‘sv2’ dbdimp.c: In function ‘ora_st_execute_array’: dbdimp.c:3328: warning: unused variable ‘sv2’ cc -c -I/var/oracle/instantclient_10_2/sdk/include -I/System/Library/ Perl/Extras/5.8.8/darwin-thread-multi-2level/auto/DBI -arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict- aliasing -Wdeclaration-after-statement -I/usr/local/include -O3 - DVERSION=\1.22\ -DXS_VERSION=\1.22\ -I/System/Library/Perl/5.8.8/ darwin-thread-multi-2level/CORE -Wall -Wno-comment -DUTF8_SUPPORT - DNEW_OCI_INIT -DORA_OCI_VERSION=\10.2.0.4\ oci8.c Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.bundle LD_RUN_PATH=/var/oracle/instantclient_10_2 cc -mmacosx-version- min=10.5.6 -arch i386 -arch ppc -bundle -undefined dynamic_lookup -L/ usr/local/lib Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/ Oracle.bundle \ -L/var/oracle/instantclient_10_2 -lclntsh\ ld warning: in
