RE: :Oracle function
[EMAIL PROTECTED] wrote: > Anyone knows if DBD::Oracle has a function similar to the function > $sth->rows that exist in DBD::Mysql? This is a DBI feature. It exists for all drivers. > This function give us the number o rows in a select command. So, we > don´t have to run a fetchrow with a while loop to know how many rows > the select will return. This is driver-specific behavior. The DBI does not guarantee this. With Oracle, you will need to either (1) fetch all the rows first, or (2) change your SQL to "select count(1) from ...". Please note that the dbi-dev list is for DBD driver authors, not general support. Please send support questions to [EMAIL PROTECTED] - Philip
FW: "the same compiler that was used..."
Hi Tim et al. Please see the suggestion below for an amendment to the DBI readme. Sounds like a good idea to me. Regards, Philip -Original Message- From: Steve Canfield [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 12:24 PM To: dbi-users@perl.org Subject: RE: "the same compiler that was used..." Thanks Philip! This morning before your email arrived it occured to me that binary Perl modules might be installed through Synatpic package manager the same way I installed gcc. For DBI and LWP that turned out to be the case. Installing libc6-dev (using Synaptic) allowed me to install the WeakRef perl module. I suspect that installing libc6-dev would have allowed me to compile DBI. So it perhaps the README for DBI could be expanded just a little. As I read the relevent section, it appears that there is only one solution to the problem: recompile Perl. Here's the section in question: "If you get compiler errors refering to Perl's own header files (.../CORE/*.h) or the compiler complains about bad options etc then there is something wrong with your installation. It is best to use a Perl that was built on the system you are trying to use and it's also important to use the same compiler that was used to build the Perl you are using." There may be two other ways to address the problem. Perhaps something like this would guide people towards solutions: "If you installed Perl using a binary distribution, such as ActiveState Perl, or if Perl came installed with the operating system you use, such as Debian or Ubuntu, then you may be able to install a precompiled binary of DBI using a package manager. Check the package manager for your distribution of Perl (e.g. ppm for ActiveState) or for your operating system (e.g Synaptic for Ubuntu). See [some URL here] for more information about package managers. You may also be able to augment your compiler with [not sure what to put here, perhaps someone in this mailing list can come up with something]." --- "Garrett, Philip (MAN-Corporate)" <[EMAIL PROTECTED]> wrote: > Steve Canfield wrote: > > "the same compiler that was used..." > > > [snip] > > > > The entirety of the output of "perl Makefile.PL", > > "make", and "perl -V" are echoed below. However, > I > > believe the problem lies in this error and others > like > > it: > > > > /usr/lib/perl/5.8/CORE/perl.h:382:24: error: > > sys/types.h: No such file or directory > > Looks to me like you need the libdevel/libc6-dev > package: > http://packages.ubuntu.com/edgy/libdevel/libc6-dev > > Good luck! > > Regards, > Philip > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Announce: DBI-1.53 release candidate 2
Tim Bunce wrote: > I'd appreciate testing of this release candidate: > > http://www.data-plan.com/public/DBI-1.53-RC2.tar.gz Hi Tim, I'm testing with 64-bit perl 5.8.3 on Linux 2.6.5. All tests pass, however there are some warnings on the thread cloning tests. Version 1.52 also has this "problem." I have not tested earlier versions. Regards, Philip t/05thrclone.ok 43/43Attempt to free unreferenced scalar: SV 0x2a96e03560 during global destruction. Attempt to free unreferenced scalar: SV 0x110ba50 during global destruction. Attempt to free unreferenced scalar: SV 0x2a96c1cef0 during global destruction. Attempt to free unreferenced scalar: SV 0x2a96a77160 during global destruction. Attempt to free unreferenced scalar: SV 0x2a968e63a0 during global destruction. Attempt to free unreferenced scalar: SV 0xed8460 during global destruction. Attempt to free unreferenced scalar: SV 0x2a96713240 during global destruction. Attempt to free unreferenced scalar: SV 0xcfe740 during global destruction. Attempt to free unreferenced scalar: SV 0x2a964447d0 during global destruction. Attempt to free unreferenced scalar: SV 0xb2aff0 during global destruction. t/zvpp_05thrcloneok 43/43Attempt to free unreferenced scalar: SV 0x21f9650 during global destruction. Attempt to free unreferenced scalar: SV 0x2a96f96680 during global destruction. Attempt to free unreferenced scalar: SV 0x1e81880 during global destruction. Attempt to free unreferenced scalar: SV 0x2a96c1ee80 during global destruction. Attempt to free unreferenced scalar: SV 0x1b36fd0 during global destruction. Attempt to free unreferenced scalar: SV 0x17ea040 during global destruction. Attempt to free unreferenced scalar: SV 0x2a96783cd0 during global destruction. Attempt to free unreferenced scalar: SV 0x1470250 during global destruction. Attempt to free unreferenced scalar: SV 0x2a9641a670 during global destruction. Attempt to free unreferenced scalar: SV 0x1109950 during global destruction. Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Platform: osname=linux, osvers=2.6.5, archname=x86_64-linux-thread-multi uname='linux salieri 2.6.5 #1 smp fri jan 14 15:41:33 utc 2005 x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -fmessage-length=0 -Wall -Wall -pipe'
RE: ANNOUNCE: DBD::Oracle 1.19 release candidate 3
John Scoles wrote: > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.19-RC3.zip > > Changes in DBD-Oracle 1.19 (svn rev 7989) > > Cleaned out the extra file problems from RC2 > Fixed execute_array so it will take the ora_array_chunk_size DB handle > attribute > Some minor changes to the POD > > Any and all testing would be greatly appreciated, but especially > testing of building against Oracle Instant Client and Oracle XE > on a range of platforms. > > Please take this opportunity to try out mass updates with > execute_array and if you can try inserting null or undef values. Hi John, It tests fine for me (Linux 2.6, Perl 5.8.3, DBI 1.50). I am curious why you moved ora_array_chunk_size into the database handle. That particular setting seems like something that would vary from statement to statement, esp. depending on the size of the bound values. Regards, Philip
RE: ANNOUNCE: DBD::Oracle 1.19 release candidate
John Scoles wrote: > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.19-RC1.zip > > Any and all testing would be greatly appreciated, but especially > testing of building against Oracle Instant Client and Oracle XE > on a range of platforms. Hi John, All tests ok for me, running on Linux i686 SMP (SLES 9). Database and client versions and character sets: Database 9.2.0.5.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is AL16UTF16 (Unicode) Client 9.2.0.4 NLS_LANG is '', NLS_NCHAR is '' Philip
RE: Getting DBD::Oracle tests working
Tim Bunce wrote:
> It would be simpler to
>
> $h->{PrintWarn} = 0;
>
> at the right spot. (Perhaps in a block and using local.)
Hi Tim,
Yeah, that would be simpler (and it's what I do in my own code), but my
impression was that John wanted to leave the warning in there to test
that it would be generated.
Regards,
Philip
RE: Getting DBD::Oracle tests working
John Scoles wrote:
>
>> t/26exe_array...DBD::Oracle::st execute_array warning:
>> ORA-24381: error(s) in array DML (DBD SUCCESS_WITH_INFO: error
>> possibly near <*> indicator at char 66 in 'INSERT INTO
>> dbd_ora__drop_me ( row_1, row_2, row_3) VALUES (:p1,:<*>p2,:p3)')
>> [for Statement "INSERT INTO dbd_ora__drop_me ( row_1, row_2, row_3)
>> VALUES (?,?,?)" with ParamValues: :p3=undef, :p1=undef, :p2=undef]
>> at t/26exe_array.t line
>> 77.
>>
>
>> Again, this doesn't seem to be particularly serious, and the install
>> proceeds anyway.
>
> You are right this is a deliberate error that is testing to see if an
> error in the tuple is returned. So you can ignore it.
Hi John,
The following patch hides the warning but still checks for its
existence.
If the long lines get wrapped, you can get the pristine patch here:
http://www.pgarrett.net/DBD-Oracle-ExeArray.patch
Regards,
Philip
--- 26exe_array.t.orig 2006-09-07 00:08:58.091338000 +1000
+++ 26exe_array.t 2006-09-07 00:07:29.814842000 +1000
@@ -4,7 +4,7 @@
use DBD::Oracle qw(ORA_RSET SQLCS_NCHAR);
use strict;
-use Test::More tests =>13 ;
+use Test::More tests =>14 ;
unshift @INC ,'t';
require 'nchar_test_lib.pl';
@@ -74,18 +74,35 @@
@var2 = (2,2,2,2,'s',2,2,2,2,2);
-ok (!$sth->execute_array(
- {ArrayTupleStatus => $tuple_status},
-[EMAIL PROTECTED],
-[EMAIL PROTECTED],
- [EMAIL PROTECTED],
- ), '... execute_array should return flase');
+{
+ # trap the intentional failure of one of these rows
+ my $warn_count = 0;
+ local $SIG{__WARN__} = sub {
+my $msg = shift;
+if ($warn_count++ == 0 && $msg =~ /ORA-24381/) {
+ # this is the first warning, and it's the expected one
+ return;
+}
+
+# unexpected warning, pass it through
+warn $msg;
+ };
+
+ ok (!$sth->execute_array(
+{ArrayTupleStatus => $tuple_status},
+ [EMAIL PROTECTED],
+ [EMAIL PROTECTED],
+ [EMAIL PROTECTED],
+ ), '... execute_array should return flase');
+
+cmp_ok(scalar @{$tuple_status}, '==', 10, '... we should have 10
tuple_status');
+
+cmp_ok( $tuple_status->[4]->[1],'ne','-1','... we should get
text');
+
+cmp_ok( $tuple_status->[3],'==',-1,'... we should get -1');
- cmp_ok(scalar @{$tuple_status}, '==', 10, '... we should have 10
tuple_status');
-
- cmp_ok( $tuple_status->[4]->[1],'ne','-1','... we should get text');
-
- cmp_ok( $tuple_status->[3],'==',-1,'... we should get -1');
+is($warn_count, 1, "... we should get a warning");
+}
# siple test with execute_for_fetch
RE: :WMI - query the Windows Management Instrumentation via the DBI
Max Maischein wrote:
> Hello all,
>
> I've just created DBD::WMI [1], which you can use to query various
> information on Windows (2000, XP, 2003) computers. My driver is a
> (very thin) layer between DBI and the Windows WQL query language. The
> WMI allows you to query various tables ("namespaces"), like the
> filesystem, currently active processes and events:
>
> SELECT * FROM Win32_Process
>
> The driver/WMI implements two kinds of queries, finite queries like
> the query above and potentially infinite queries for events as they
> occur in the system:
>
> SELECT * FROM __instanceoperationevent
> WITHIN 1
> WHERE TargetInstance ISA 'Win32_DiskDrive'
>
> This query returns one row (via ->fetchrow_arrayref() ) whenever a
> disk drive gets added to or removed from the system (think USB stick).
>
> The driver is a very rough draft, lacking documentation, error
> checking and other stuff, but it works so far. What's on the plan
> already are DSN parameters to specify the credentials and machine to
> connect to. Other stuff is welcome - a CPAN release will come soonish.
>
> What helped me greatly were the DBD::File prototype, but more
> importantly, the DBI::DBD documentation was what made me finish the
> implementation.
This is really cool. Thanks, Max.
Philip
RE: ANNOUNCE: DBD::Oracle 1.18 release candidate 2
Martin J. Evans wrote:
> On Fri, 2006-07-14 at 14:11 -0400, Garrett, Philip (MAN-Corporate)
> wrote:
>> John Scoles wrote:
>>>
>>> Not sure what wait.ph is for?
>>
>> Found this -- it's an error in my system's bits/typesizes.ph. Not
>> your problem.
>
> I think I reported the same issue a few days ago.
> What was the problem?
My typesizes.ph has this line:
eval 'sub __FSID_T_TYPE {\'struct struct\' { \'int\' $__val[2];
};}' unless defined(&__FSID_T_TYPE);
It looks like a bug (or missing feature) where h2ph is unable to parse
my system's headers. I'm running Linux kernel 2.6.5. The offending
line in /usr/include/bits/typesizes.ph is:
#define __FSID_T_TYPE struct { int __val[2]; }
Philip
RE: ANNOUNCE: DBD::Oracle 1.18 release candidate 2
John Scoles wrote: > > Not sure what wait.ph is for? Found this -- it's an error in my system's bits/typesizes.ph. Not your problem. Philip
RE: ANNOUNCE: DBD::Oracle 1.18 release candidate 2
John Scoles wrote: > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.18-RC2.zip > > =head1 Changes in DBD-Oracle 1.18 (scn rev 6647) > > Updated README.win32.txt fixed for some more typos > Fixed some waring messages found in > > Oracle.xs > dbdimp.c > and oci8.c > > and added the test > > t\26exe_array.t > > So far things look good and thanks for all the testing. Look like we > can get this out next week sometime. > > Any and all testing would be greatly appreciated, but especially > testing of building against Oracle Instant Client and Oracle XE > on a range of platforms. I'm running SUSE LINUX Enterprise Server 9 (i586). Although it compiled without errors and the tests ran fine, I received these warnings: Warning: the following files are missing in your kit: META.yml Checking for functioning wait.ph Scalar found where operator expected at (eval 209) line 1, near "'int' $__val" (Missing operator before $__val?) DBD::Oracle::st execute_array warning: ORA-24381: error(s) in array DML (DBD SUCCESS_WITH_INFO: error possibly near <*> indicator at char 66 in 'INSERT INTO dbd_ora__drop_me ( row_1, row_2, row_3) VALUES (:p1,:<*>p2,:p3)') [for Statement "INSERT INTO dbd_ora__drop_me ( row_1, row_2, row_3) VALUES (?,?,?)" with ParamValues: :p3=undef, :p1=undef, :p2=undef] at t/26exe_array.t line 77. Philip DEFINE _SQLPLUS_RELEASE = "902000400" (CHAR) Oracle version 9.2.0.4 (9.2) Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Platform: osname=linux, osvers=2.6.5, archname=i586-linux-thread-multi uname='linux oldboy 2.6.5 #1 smp fri nov 18 15:22:13 utc 2005 i686 i686 i386 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -Wall -pipe' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing' ccversion='', gccversion='3.3.3 (SuSE Linux)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='' libpth=/lib /usr/lib /usr/local/lib libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.3/i586-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 Built under linux Compiled at Dec 17 2005 03:24:12 @INC: /usr/lib/perl5/5.8.3/i586-linux-thread-multi /usr/lib/perl5/5.8.3 /usr/lib/perl5/site_perl/5.8.3/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.3/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl .
DBD::Oracle error when switching between utf8 and non-utf8
[ This got warnocked on dbi-users, so I'm posting here too.
When I originally posted, I was using DBI 1.41. I have since
upgraded to DBI 1.50 which did not help. ]
Hi list.
I believe I have tripped a DBD::Oracle bug in the way it binds utf8
parameters. If I create a statement and execute it with a non-utf8
parameter, it works. If I then execute that *same sth* with a utf8
parameter (scalar with UTF8 flag on), I receive the following error:
ORA-01460: unimplemented or unreasonable conversion requested
Example:
use Encode qw(decode);
my $sth = $dbh->prepare("select ? from dual") || die $dbh->errstr;
my $non_utf8 = "X";
$sth->execute($non_utf8) || die $sth->errstr;
my $utf8 = decode('utf8', $non_utf8);
$sth->execute($utf8) || die $sth->errstr; # DIES
The problem does *NOT* occur when:
1) the order is reversed (utf8 before non-utf8) or
2) the statement is prepared again before the second execute or
3) NLS_LANG does not indicate utf8 or
4) ora_csform is specified as SQLCS_NCHAR or SQLCS_IMPLICIT.
I made a script for the test suite to reproduce the problem. You can get it
from
http://www.pgarrett.net/rebind_nchar.t
Is this the appropriate forum for this kind of thing? Should I post elsewhere
also?
Thanks much,
Philip
All of my DBI and DBD::Oracle tests passed.
Perl: 5.8.3
DBI: 1.50
DBD::Oracle: 1.17
OS: Linux 2.6.5
Oracle server: 9.2.5
Oracle client: 9.2.4
Oracle database charset: US7ASCII
Oracle nchar charset: AL16UTF16
NLS_LANG env var: AMERICAN_AMERICA.AL32UTF8
Here are the bits from DBI trace that looked relevant:
First execution (non-utf8):
-> execute for DBD::Oracle::st (DBI::st=HASH(0x84121f8)~0x8416818 'X')
thr#814f008
bind :p1 <== 'X' (type 0)
rebinding :p1 (not-utf8, ftype 1, csid 0, csform 0, inout 0)
bind :p1 <== 'X' (size 1/2/0, ptype 4, otype 1)
bind :p1 <== 'X' (size 1/1, otype 1, indp 0, at_exec 1)
bind :p1 <== 'X' (in, not-utf8, csid 1->0->1, ftype 1, csform 0->0,
maxlen 1, maxdata_size 0)
Second execution (utf8):
-> execute for DBD::Oracle::st (DBI::st=HASH(0x84121f8)~0x8416818 "X")
thr#814f008
bind :p1 <== "X" (type 0)
rebinding :p1 (is-utf8, ftype 1, csid 0, csform 0, inout 0)
bind :p1 <== "X" (size 1/2/0, ptype 4, otype 1)
bind :p1 <== 'X' (size 1/1, otype 1, indp 0, at_exec 1)
rebinding :p1 with UTF8 value so setting csform=SQLCS_IMPLICIT
bind :p1 <== "X" (in, is-utf8, csid 1->0->871, ftype 1, csform 0->2, maxlen 1,
maxdata_size 0)
dbd_st_execute SELECT (out0, lob0)...
in ':p1' [0,0]: len 1, ind 0
OCIErrorGet after OCIStmtExecute (er1:ok): -1, 1460: ORA-01460:
unimplemented or unreasonable conversion requested
