DBI::PurePerl and DBD::Oracle error
Hi,
I'm trying to run some perl (currently 5.00503) on AIX 4.3 to connect an
Oracle 8 database on the same system (DBD::Oracle is 1.06)
My problem is that I want to use the HandleError method of DBI but I
only find a pre-compiled version of DBI 1.14 which doens't have this
method yet.
As I can't compile anything on this system, I'm trying to use
DBI::PurePerl (I don't need performance and only want to do a SELECT and
some little UPDATE).
With this little script, I got an error :
Use of uninitialized value at
/usr/opt/perl5/lib/5.00503/aix/DynaLoader.pm line 188.
error: install_driver(Oracle) failed: Unable to get DBI state. DBI not
loaded. at /usr/opt/perl5/lib/5.00503/aix/DynaLoader.pm line 188.
at testoracle.pl line 15
BEGIN {
$ENV{DBI_PUREPERL} = 2;
$ENV{ORACLE_HOME} = /oracle;
unshift INC, 'lib';
}
use strict;
use DBI;
my $dbh;
eval {
$dbh = DBI-connect(
DBI:Oracle:sid=ORCL;port=1521;host=oracle_host,
username,
password
);
};
if ( $ ) {
print error: $@\n;
}
Re: DBI::PurePerl and DBD::Oracle error
You can't use DBI::PurePerl with a NON-pure-perl driver.
Tim.
On Mon, Oct 14, 2002 at 08:19:57AM +0200, Frederic Van de Velde wrote:
Hi,
I'm trying to run some perl (currently 5.00503) on AIX 4.3 to connect an
Oracle 8 database on the same system (DBD::Oracle is 1.06)
My problem is that I want to use the HandleError method of DBI but I
only find a pre-compiled version of DBI 1.14 which doens't have this
method yet.
As I can't compile anything on this system, I'm trying to use
DBI::PurePerl (I don't need performance and only want to do a SELECT and
some little UPDATE).
With this little script, I got an error :
Use of uninitialized value at
/usr/opt/perl5/lib/5.00503/aix/DynaLoader.pm line 188.
error: install_driver(Oracle) failed: Unable to get DBI state. DBI not
loaded. at /usr/opt/perl5/lib/5.00503/aix/DynaLoader.pm line 188.
at testoracle.pl line 15
BEGIN {
$ENV{DBI_PUREPERL} = 2;
$ENV{ORACLE_HOME} = /oracle;
unshift INC, 'lib';
}
use strict;
use DBI;
my $dbh;
eval {
$dbh = DBI-connect(
DBI:Oracle:sid=ORCL;port=1521;host=oracle_host,
username,
password
);
};
if ( $ ) {
print error: $@\n;
}
Re: DBD-ADO, getting started with
Thomas A. Lowery wrote:
Roger,
My work with DBD-ADO and stored procedures is very limited. If you could
provide me with a few (at least one) complete example that generates this
error, fixing it would be much easier. Also, I haven't a lot of time to
work on DBD-ADO.
My main focus is on DBD-ODBC but I found a bug that haven't been fixed
yet. I therefore thought I might give DBD-ADO a try.
However nothing(!) seem to work for me with DBD-ADO (Using MS SQL 7.0
MDAC 2.7 DBI 1.30 Activeperl 631):
my $dbh = newDbh();
my $sth = $dbh-prepare(select * from sysobjects);
$sth-execute();
Results in:
E:\Projekt\Helpdesk\Perl\UpgradeDBdbitest4ado.pl
DSN: DRIVER={SQL
Server};SERVER=(local);DATABASE=Helpdesk2;NETWORK=dbmssocn;UID=sa;PWD=
OLE exception from ADODB.Connection:
Object or provider is not capable of performing requested operation.
Win32::OLE(0.1502) error 0x800a0cb3
in METHOD/PROPERTYGET OpenSchema at E:/Perl/site/lib/DBD/ADO.pm
line 1402
OLE exception from ADODB.Connection:
Error is repeated for each column in sysobjects
I do recall the bind interface (also with parameter support) is a little
tricky. A quick review of the 09bind.t tests, they look like the original
tests I grabbed from DBD::ODBC and DBD::Oracle.
I know calling a sp is database dependent ... Oracle uses begin; sp_call;
end; Where as PostgreSQL uses select sp_call;
The code is executed by the server. It's when the result is interpreted
something goes wrong.
snip
Finally my questions:
1. Why do I get those errors?
Not sure at the moment.
I've reinstalled using the new ppm package, didn't help. If I change
from ADO to ODBC in
$dbh = DBI-connect(DBI:ADO:$dsn)
my program works.
2. Is DBD-ADO mature? Experiences?
Limited ...
I've tested it because DBD:ODBC is not mature enough for me...
3. Does DBD-ADO support input/output parameters for stored procedures?
No or at least I doubt it.
Multiple result sets?
No.
4. I've noticed that DBD-ADO call sp_sproc_columns for my sp's, can
that be avoided?
This looks like something the ADO driver is using. There isn't any
sp_sproc_columns in the DBD::ADO code that I know of.
It's not an important feature. You have to be very specific to avoid the
call to sp_sproc_columns. If I use ADO command objects directly and
specify the parameters like this (Javascript):
cmdTemp = Server.CreateObject('ADODB.Command');
cmdTemp.CommandText = dbo.my_stored_procedure;
cmdTemp.CommandType = adCmdStoredProc;
cmdTemp.Parameters.Append(cmdTemp.CreateParameter(RETURN_VALUE,
adInteger, adParamReturnValue, 4));
cmdTemp.Parameters.Append(cmdTemp.CreateParameter(Cmd, adInteger,
adParamInput, 4, cmd));
cmdTemp.Execute();
Then ADO will know the parameters (trust my declaration) before calling
Execute and avoid the round trip to the server (sp_sproc_columns).
Since there is no way (I assume) to specify the type of command in
DBD-ADO it's not possible to do this in DBI.
/Roger P
RE: 5.8, NLS_LANG, and the utf8 flag
It is my impression that the utf flag isn't set unless you explicitly set it. That seems to impact program stuff rather than data, and that may best be set by the statement use utf8; Tim Vorce Ford Motor Company [EMAIL PROTECTED] -Original Message- From: Kevin Scaldeferri [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 6:21 PM To: [EMAIL PROTECTED] Subject: 5.8, NLS_LANG, and the utf8 flag I didn't see anything which explicitly confirmed this in a couple google searches on this group, so... I observe that when I set NLS_LANG=AMERICAN_AMERICA.UTF8 that while I retrieve the correct bytes from the database, the utf8 flag is not set. Is this correct or am I possibly not setting up my connection correctly. I'm using Oracle, if it matters at all, and versions of everything from about 2 months ago, so maybe there are newer versions that fix this? Thanks, Kevin (P.S. I posted this once through google, but they don't think this groups is moderated, and apparently that kept it from going out the first time. I think. Apologies to anyone who sees this twice)
DBD::Informix build failure
using CSDK 2.80 (on Linux, at least), the output from esql -V has changed. That breaks the version parsing in DBD/Informix/Configuration.pm . Bug report below. I made a few changes to make this script more failsafe. Don't know if this is the best way, though. Here are the diffs: --- DBD/Informix/Configuration-old.pm Mon Oct 14 12:55:49 2002 +++ DBD/Informix/Configuration.pm Mon Oct 14 12:57:15 2002 @@ -105,9 +105,9 @@ $infv =~ s/\s+$//; # Delete trailing white space $infv =~ s/\s+/ /g; # Replace white space with single blanks $vers = $infv; - $vers =~ s/INFORMIX.* Version (\d+[.]\d+).*/$1/; - die Unexpected message from esql script -- $infv\n - unless ($vers =~ /\d+[.]\d+/); + $vers =~ s/^.*INFORMIX.* Version (\d+[.]\d+).*/$1/i; + die Unexpected message from esql script -- $infv ($vers)\n + unless ($vers =~ /^\d+[.]\d+$/); $vers =~ s/^([0-9])\./$1/; return $infv, $vers; After these changes, the build was straightforward. Output from BugReport: Command: BugReport A Date: Mon Oct 14 12:44:37 CEST 2002 Machine: itlnx (Linux 2.4.9-34) User: uid=116(ogj) gid=30(gopher) groups=30(gopher) Directory: /var/tmp/DBD-Informix-1.00.PC2 Umask: 022 Terminal: /dev/pts/1 # # Perl Version Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.17-0.13smp, archname=i386-linux uname='linux daffy.perf.redhat.com 2.4.17-0.13smp #1 smp fri feb 1 10:30:48 est 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386 -linux -Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -D i_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Dlocincpth=' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=unde f useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.1 2.96-98)', gccosa ndvers='' 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 =4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: Built under linux Compiled at Feb 20 2002 15:01:16 @INC: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl . # # Informix Version INFORMIXDIR = /opt/informix ESQLC = esql Version = IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.UC2 DBMS Version = *** indeterminate *** Informix Server Entries in sqlhosts file dbprod onsoctcpdbprod dbprod_sql # # Sorted Environment ANT_HOME=/opt/jakarta-ant-1.5.1beta1 DISPLAY=localhost:10.0 HISTSIZE=1000 HOME=/home/ogj HOSTNAME=itlnx HOSTTYPE=i386 INFORMIXDIR=/opt/informix INFORMIXSERVER=dbprod INPUTRC=/etc/inputrc J2EE_HOME=/usr/java/j2sdkee1.3.1 JAVA_HOME=/usr/java/j2sdk1.4.1 JDK_HOME=/usr/java/j2sdk1.4.1 LANG=en_US LESSOPEN=|/usr/bin/lesspipe.sh %s LOGNAME=ogj LS_COLORS= MACHTYPE=i386-redhat-linux-gnu MAIL=/var/spool/mail/ogj OLDPWD=/var/tmp OSTYPE=linux-gnu PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/opt/jakarta-ant-1.5.1beta1/bin :/opt/informix/bin:/usr/java/j2sdkee1.3.1/bin:/usr/java/j2sdk1.4.1/bin:/home/ogj /bin PWD=/var/tmp/DBD-Informix-1.00.PC2 QTDIR=/usr/lib/qt-2.3.1 SHELL=/bin/bash SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SSH_TTY=/dev/pts/1 TERM=xterms TOMCAT_HOME=/opt/jakarta-tomcat-4.1.10 USER=ogj _=/usr/bin/perl # End of Configuration Report # # Redoing configuration + [ ! -f Makefile ] || make realclean + rm -f esql esqlvrsn.h esqlinfo.h + perl Makefile.PL Configuring IBM Informix Database Driver for Perl Version
1)convert from ascii to char,2) example of using showErrorstatement
Hi, Probably,This is not a question for the dbi group. 1) Could anyone tell me how to convert an ascii value of a char to the character itself. Another request. 2) Could anyone give me an example of using an showErrorStatement passing the values. thank you.Naveen __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Wrong ELF Class when running make for DBD-Oracle-1.12 module
When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga
go further in the error
I wanted to know if it were possible of recuperer the
place of code SQL or the error occurred.
I could recuperer $$dbh-{errstr },
I seek more precision if that exists. Thank you and
good day.
___
Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: 5.8, NLS_LANG, and the utf8 flag
Tim Vorce wrote:
It is my impression that the utf flag isn't set unless you explicitly set it. That
seems to impact program stuff rather than data, and that may best be set by the
statement
use utf8;
In Perl 5.8, 'use utf8' is 99% no-op. It is documented as only being
necessary to recognize utf8 literals in your source code. You should
never need 'use utf8' anymore to handle data.
It seems dramatically wrong for bytes known to be utf8 to be passed
without the utf8 bit set. It requires people to manually correct all
uses like:
while ($sth-fetch()) {
if ($ENV{'NLS_LANG') =~ /UTF8$/) {
Encode::_utf8_on($result);
}
...
}
Slightly OT - Convert column in Postgres
I am using Perl DBI to do this conversion, so this is somewhat related to DBI. I need to convert a column in a Postgres table from VARCHAR to INTEGER - I don't know of an easy way to do that, so I'm assuming I need to do something drastic like this in my conversion script: * create a new table - with all existing columns except VARCHAR column I don't want, and with new INTEGER column * populate rows with rows from old table, and populate new INTEGER column properly * once new table populated, delete old table * rename new table to old table name A couple of hitches - the table has a primary key and a sequence, but there are no other tables which use that primary key. Is there an easier way? What am I missing? TIA. Hardy Merrill
Re: Wrong ELF Class when running make for DBD-Oracle-1.12 module
You can't link against the 64-bit version unless your Perl (and by extension all modules including DBI and DBD::Oracle) is built with maximal 64-bit support. The problem is that it is not possible to mix and match linking 32-bit and 64-bit libraries. If you do build your Perl as 64-bit, you will then no longer be able to link it to any 32-bit libraries (including everything in /opt/sfw/lib and any libraries that are not explicitly 64-bit) unless you build 64-bit versions of those libraries. Hope this helps. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga - D [EMAIL PROTECTED]
Re: Slightly OT - Convert column in Postgres
On Monday, October 14, 2002, at 11:30 AM, Hardy Merrill wrote: Is there an easier way? What am I missing? Yes, there is: PostgreSQL 7.3. It's still in beta, but should be in final release soon. It finally adds good ALTER COLUMN support. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Slightly OT - Convert column in Postgres
David Wheeler [[EMAIL PROTECTED]] wrote: On Monday, October 14, 2002, at 11:30 AM, Hardy Merrill wrote: Is there an easier way? What am I missing? Yes, there is: PostgreSQL 7.3. It's still in beta, but should be in final release soon. It finally adds good ALTER COLUMN support. Are you sure - I just checked the Postgres 7.3b2 docs at http://developer.postgresql.org/docs/postgres/sql-commands.html and there is no mention of an ALTER COLUMN command. Hardy
Re: Slightly OT - Convert column in Postgres
On Monday, October 14, 2002, at 11:50 AM, Hardy Merrill wrote: Are you sure - I just checked the Postgres 7.3b2 docs at http://developer.postgresql.org/docs/postgres/sql-commands.html and there is no mention of an ALTER COLUMN command. Sorry, bad memory. It's DROP COLUMN that's been added. This is from the HISTORY file: PostgreSQL now supports ALTER TABLE ... DROP COLUMN functionality. But what that means is that you can rename your old column, add a new column with the new data type, select all the data from the old column into the new column, and then drop the new column. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Slightly OT - Convert column in Postgres
David Wheeler wrote: Sorry, bad memory. It's DROP COLUMN that's been added. This is from the HISTORY file: PostgreSQL now supports ALTER TABLE ... DROP COLUMN functionality. But what that means is that you can rename your old column, add a new column with the new data type, select all the data from the old column into the new column, and then drop the new column. HTH, David not to be a smart ass(gonna be one anyways), but after all that work, wouldnt you want to keep your new column? :) chris -- --- Just Your Friendly Neighborhood _SPIDEY_
Re: Slightly OT - Convert column in Postgres
On Monday, October 14, 2002, at 11:57 AM, Christopher G Tantalo wrote: not to be a smart ass(gonna be one anyways), but after all that work, wouldnt you want to keep your new column? :) D'oh! I mean drop the old column. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
When I execute my perl code to connect to the Oracle databse using the 32 Bit version of DBD-Oracle, I encounter the error below even though LD_LIBRARY_PATH points to the 32 bit libraries. Is there anything else that I need to set for this to work properly ? Can't connect to database: install_driver(Oracle) failed: Can't load '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so ' for module DBD::Oracle: ld.so.1: /usr/local/bin/perl: fatal: /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at (eval 14) line 3 Compilation failed in require at (eval 14) line 3. Cheers. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 2:32 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: Re: Wrong ELF Class when running make for DBD-Oracle-1.12 module You can't link against the 64-bit version unless your Perl (and by extension all modules including DBI and DBD::Oracle) is built with maximal 64-bit support. The problem is that it is not possible to mix and match linking 32-bit and 64-bit libraries. If you do build your Perl as 64-bit, you will then no longer be able to link it to any 32-bit libraries (including everything in /opt/sfw/lib and any libraries that are not explicitly 64-bit) unless you build 64-bit versions of those libraries. Hope this helps. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga - D [EMAIL PROTECTED]
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
Run this command: file /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0 If it tells you that it is a 64-bit ELF library, it's the 64-bit version. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When I execute my perl code to connect to the Oracle databse using the 32 Bit version of DBD-Oracle, I encounter the error below even though LD_LIBRARY_PATH points to the 32 bit libraries. Is there anything else that I need to set for this to work properly ? Can't connect to database: install_driver(Oracle) failed: Can't load '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so ' for module DBD::Oracle: ld.so.1: /usr/local/bin/perl: fatal: /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at (eval 14) line 3 Compilation failed in require at (eval 14) line 3. Cheers. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 2:32 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: Re: Wrong ELF Class when running make for DBD-Oracle-1.12 module You can't link against the 64-bit version unless your Perl (and by extension all modules including DBI and DBD::Oracle) is built with maximal 64-bit support. The problem is that it is not possible to mix and match linking 32-bit and 64-bit libraries. If you do build your Perl as 64-bit, you will then no longer be able to link it to any 32-bit libraries (including everything in /opt/sfw/lib and any libraries that are not explicitly 64-bit) unless you build 64-bit versions of those libraries. Hope this helps. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga - D [EMAIL PROTECTED] - D [EMAIL PROTECTED]
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
This is because your attempting to build in a 32 bit Perl against a 64bit oracle install. Here's the solution form Stephen Clouse: The best solution is to edit the Makefile generated by Makefile.PL and change all references to ORACLE_HOME/lib to ORACLE_HOME/lib32. This will get it to use the 32-bit Oracle libraries instead. David Crown, MCSE, MCP+I, CCNA Information Resources Management State of Delaware, Department of Natural Resources and Environmental Control [EMAIL PROTECTED] Voice: (302)739-4409 Fax: (302)739-6242 www.dnrec.state.de.us/ -Original Message- From: Kwabbi, Seth [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 14:23 To: '[EMAIL PROTECTED]' Subject: Wrong ELF Class when running make for DBD-Oracle-1.12 module When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
It is 64 bit, but why is the DynaLoader using 64 bit libraries whilst LD_LIBRARY_PATH points to the 32 bit libraries ? Thanks. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 3:10 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module Run this command: file /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0 If it tells you that it is a 64-bit ELF library, it's the 64-bit version. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When I execute my perl code to connect to the Oracle databse using the 32 Bit version of DBD-Oracle, I encounter the error below even though LD_LIBRARY_PATH points to the 32 bit libraries. Is there anything else that I need to set for this to work properly ? Can't connect to database: install_driver(Oracle) failed: Can't load '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so ' for module DBD::Oracle: ld.so.1: /usr/local/bin/perl: fatal: /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at (eval 14) line 3 Compilation failed in require at (eval 14) line 3. Cheers. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 2:32 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: Re: Wrong ELF Class when running make for DBD-Oracle-1.12 module You can't link against the 64-bit version unless your Perl (and by extension all modules including DBI and DBD::Oracle) is built with maximal 64-bit support. The problem is that it is not possible to mix and match linking 32-bit and 64-bit libraries. If you do build your Perl as 64-bit, you will then no longer be able to link it to any 32-bit libraries (including everything in /opt/sfw/lib and any libraries that are not explicitly 64-bit) unless you build 64-bit versions of those libraries. Hope this helps. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga - D [EMAIL PROTECTED] - D [EMAIL PROTECTED]
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
DBD::Oracle's shared object library is linking to the only library it finds. If it is getting /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0 it is because that is the first libclntsh.so.9.0 in the LD_LIBRARY_PATH, and if it isn't 32-bit then the problem is that LD_LIBRARY_PATH should not include that directory. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: It is 64 bit, but why is the DynaLoader using 64 bit libraries whilst LD_LIBRARY_PATH points to the 32 bit libraries ? Thanks. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 3:10 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module Run this command: file /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0 If it tells you that it is a 64-bit ELF library, it's the 64-bit version. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When I execute my perl code to connect to the Oracle databse using the 32 Bit version of DBD-Oracle, I encounter the error below even though LD_LIBRARY_PATH points to the 32 bit libraries. Is there anything else that I need to set for this to work properly ? Can't connect to database: install_driver(Oracle) failed: Can't load '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so ' for module DBD::Oracle: ld.so.1: /usr/local/bin/perl: fatal: /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at (eval 14) line 3 Compilation failed in require at (eval 14) line 3. Cheers. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 2:32 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: Re: Wrong ELF Class when running make for DBD-Oracle-1.12 module You can't link against the 64-bit version unless your Perl (and by extension all modules including DBI and DBD::Oracle) is built with maximal 64-bit support. The problem is that it is not possible to mix and match linking 32-bit and 64-bit libraries. If you do build your Perl as 64-bit, you will then no longer be able to link it to any 32-bit libraries (including everything in /opt/sfw/lib and any libraries that are not explicitly 64-bit) unless you build 64-bit versions of those libraries. Hope this helps. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga - D [EMAIL PROTECTED] - D [EMAIL PROTECTED] - D [EMAIL PROTECTED]
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
No, the first libclitsh.so.9.o point to the lib32 libraries, otherwise the make would not have worked. The issue here is more of a run time problem, when the Dynamic Loader attempts to load the shared library. Thanks. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 3:38 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module DBD::Oracle's shared object library is linking to the only library it finds. If it is getting /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0 it is because that is the first libclntsh.so.9.0 in the LD_LIBRARY_PATH, and if it isn't 32-bit then the problem is that LD_LIBRARY_PATH should not include that directory. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: It is 64 bit, but why is the DynaLoader using 64 bit libraries whilst LD_LIBRARY_PATH points to the 32 bit libraries ? Thanks. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 3:10 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module Run this command: file /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0 If it tells you that it is a 64-bit ELF library, it's the 64-bit version. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When I execute my perl code to connect to the Oracle databse using the 32 Bit version of DBD-Oracle, I encounter the error below even though LD_LIBRARY_PATH points to the 32 bit libraries. Is there anything else that I need to set for this to work properly ? Can't connect to database: install_driver(Oracle) failed: Can't load '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so ' for module DBD::Oracle: ld.so.1: /usr/local/bin/perl: fatal: /u01/app/oracle/product/9.0.1/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at (eval 14) line 3 Compilation failed in require at (eval 14) line 3. Cheers. -Original Message- From: David M. Lloyd [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 2:32 PM To: Kwabbi, Seth Cc: '[EMAIL PROTECTED]' Subject: Re: Wrong ELF Class when running make for DBD-Oracle-1.12 module You can't link against the 64-bit version unless your Perl (and by extension all modules including DBI and DBD::Oracle) is built with maximal 64-bit support. The problem is that it is not possible to mix and match linking 32-bit and 64-bit libraries. If you do build your Perl as 64-bit, you will then no longer be able to link it to any 32-bit libraries (including everything in /opt/sfw/lib and any libraries that are not explicitly 64-bit) unless you build 64-bit versions of those libraries. Hope this helps. On Mon, 14 Oct 2002, Kwabbi, Seth wrote: When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga - D [EMAIL PROTECTED] - D [EMAIL PROTECTED] - D [EMAIL PROTECTED]
RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module
On Mon, 14 Oct 2002, Kwabbi, Seth wrote: No, the first libclitsh.so.9.o point to the lib32 libraries, otherwise the make would not have worked. The issue here is more of a run time problem, when the Dynamic Loader attempts to load the shared library. Then all I can think of is that the LD_LIBRARY_PATH you used at build time is not the same as the LD_LIBRARY_PATH you are using at runtime. - D [EMAIL PROTECTED]
Re: Which shared memory module to use?
On Fri, 2002-10-11 at 14:27, Henri Asseily wrote: Regarding what I've dubbed DBIx::HA, here's the idea: There hasn't been up to now (or at least I haven't found any) a widely available Perl/DBI-based system for system architects who handle high-availability groups of servers, either in read-only load-balanced mode or read-write hot-backup mode. Oracle, Sybase and others do offer high-availability options, but they cost upward of $30,000 for a single implementation. In addition, I tested Sybase's OpenSwitch which does not cooperate properly with DBI, but that's a story for another day. That's almost certainly an issue with DBD::Sybase. It's probably not handling (or passing) the proper connection attributes (at the C / Sybase API level). Michael -- Michael Peppler / [EMAIL PROTECTED] / http://www.mbay.net/~mpeppler [EMAIL PROTECTED] / ZetaTools, Inc / http://www.zetatools.com ZetaTools: Call perl functions as Sybase stored procedures! signature.asc Description: This is a digitally signed message part
RE: FAQ ???- Wrong ELF Class...
Is this in the FAQ? If not, David, can you please add it:-) Thanks a bunch. Ilya -Original Message- From: Crown David T. (DNREC) To: Kwabbi, Seth; [EMAIL PROTECTED] Sent: 10/14/02 1:15 PM Subject: RE: Wrong ELF Class when running make for DBD-Oracle-1.12 module This is because your attempting to build in a 32 bit Perl against a 64bit oracle install. Here's the solution form Stephen Clouse: The best solution is to edit the Makefile generated by Makefile.PL and change all references to ORACLE_HOME/lib to ORACLE_HOME/lib32. This will get it to use the 32-bit Oracle libraries instead. David Crown, MCSE, MCP+I, CCNA Information Resources Management State of Delaware, Department of Natural Resources and Environmental Control [EMAIL PROTECTED] Voice: (302)739-4409 Fax: (302)739-6242 www.dnrec.state.de.us/ -Original Message- From: Kwabbi, Seth [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 14:23 To: '[EMAIL PROTECTED]' Subject: Wrong ELF Class when running make for DBD-Oracle-1.12 module When running make for the DBD-Oracle-1.12 module, I encounter this error: ld: fatal: file /u01/app/oracle/product/9.0.1/lib//libclntsh.so: wrong ELF class: ELFCLASS64 My environment Solaris 2.8 ( 64 Bit ) and using gcc compiler version 2.95.3 20010315 ( release). Also know if I set LD_LIBRARY_PATH to point to the Oracle lib32 libraries it will work, howver I prefer make to use the 64 Bit version. Does anyone know what causes this problem ? Cheers. Seth Kwabbi ACS - DSS Atlanta, Ga
DBD-Oracle 1.12 symbol not found
I've been beating my head on this all afternoon. I've searched the web, read the README files, and have run out of ideas. I'm trying to build DBD-Oracle 1.12 on Solaris 7. I've got the Solaris 8.1.7 client installed in /opt/oracle/oracle8i/8170-SUN. I've set ORACLE_HOME, ORACLE_SID, and ORACLE_USERID. I've tried building this with gcc, Sun's Forte Workshop cc, and anything else I could find (being sure to do a make clean;perl Makefile.PL and start from scratch each time.) I saw the note in README.help about Solaris, GCC, getting GNU as and ld out of the way, didn't help. This is driving me nuts! I don't remember having so many problems when I built 1.06. (butthead:682)$ make test PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/apps/plx/lib/perl5/5.6.0/sun4-solaris -I/apps/plx/lib/perl5/5.6.0 -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests ARGV;' t/*.t t/base...Failed to load Oracle extension and/or shared libraries: install_driver(Oracle) failed: Can't load 'blib/arch/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: /usr/bin/perl: fatal: relocation error: file blib/arch/auto/DBD/Oracle/Oracle.so: symbol OCIServerAttach: referenced symbol not found at /apps/plx/lib/perl5/5.6.0/sun4-solaris/DynaLoader.pm line 200. at (eval 1) line 3 Compilation failed in require at (eval 1) line 3. Perhaps a required shared library or dll isn't installed where expected at t/base.t line 19 The remaining tests will probably also fail with the same error.
Re: 5.8, NLS_LANG, and the utf8 flag
On Mon, Oct 14, 2002 at 10:42:10AM -0700, Kevin Scaldeferri wrote:
Tim Vorce wrote:
It is my impression that the utf flag isn't set unless you explicitly set
it. That seems to impact program stuff rather than data, and that may
best be set by the statement
use utf8;
In Perl 5.8, 'use utf8' is 99% no-op. It is documented as only being
necessary to recognize utf8 literals in your source code. You should
never need 'use utf8' anymore to handle data.
It seems dramatically wrong for bytes known to be utf8 to be passed
without the utf8 bit set. It requires people to manually correct all
uses like:
while ($sth-fetch()) {
if ($ENV{'NLS_LANG') =~ /UTF8$/) {
Encode::_utf8_on($result);
}
...
}
Though putting a $ENV lookup and a regex inside a loop isn't the
way to performance happiness :)
The next release of DBD::Oracle should include the attached patch from
Stefan Eissing [EMAIL PROTECTED] (or something like it),
which will probably help.
Tim.
Tim,
attached is the current diff against 1.03 of my utf8 port.
With Perl 5.6.0 patchlevel 6090, all tests pass. I've
added select.t to test (VAR)CHAR(2) and utf8 behaviour.
One annoyance is that pre5.6.0 versions now give warning
about illegal hex chars in long.t/select.t (because of the
unicode constants).
This patch has the following improvements compared to the last:
a) it works with utf8 chars in CHAR/VARCHAR columns
b) it marks strings with UTF8 only when 8-bit chars are present.
this should give better performance as perl can skip the utf8
special handling more often (at least in the U.S. that is)
c) there is a readme about utfishiness
d) it was even more fun. Sarathy was very helpful and I supplied
my first patches to Perl itself. ;)
Stefan
*** //c/usr/local/src/DBD-Oracle-1.03//./dbdimp.c Mon Jul 12 05:21:10 1999
--- ./dbdimp.c Tue May 09 10:58:37 2000
***
*** 23,28
--- 23,32
int ora_fetchtest;
+ #ifdef UTF8_SUPPORT
+ int cs_is_utf8;
+ #endif
+
static int ora_login_nomsg; /* don't fetch real login errmsg if true */
static int ora_sigchld_restart = 1;
#ifndef OCI_V8_SYNTAX
***
*** 45,50
--- 49,63
ora_login_nomsg = atoi(getenv(DBD_ORACLE_LOGIN_NOMSG));
if (getenv(DBD_ORACLE_SIGCHLD))
ora_sigchld_restart = atoi(getenv(DBD_ORACLE_SIGCHLD));
+ #ifdef UTF8_SUPPORT
+ {
+ char *nls = getenv(NLS_LANG);
+ STRLEN nlslen;
+ if (nls (nlslen = strlen(nls)) = 4) {
+ cs_is_utf8 = !stricmp(nls + nlslen - 4, utf8);
+ }
+ }
+ #endif
}
***
*** 1341,1347
--- 1354,1364
else
/* phs-alen has been updated by Oracle to hold the length of the result
*/
if (phs-indp == 0) { /* is okay */
+ #ifdef UTF8_SUPPORT
+ SvPOK_only_UTF8(sv);
+ #else
SvPOK_only(sv);
+ #endif
SvCUR(sv) = phs-alen;
*SvEND(sv) = '\0';
if (debug = 2)
***
*** 1351,1357
--- 1368,1378
}
else
if (phs-indp 0 || phs-indp == -2) { /* truncated*/
+ #ifdef UTF8_SUPPORT
+ SvPOK_only_UTF8(sv);
+ #else
SvPOK_only(sv);
+ #endif
SvCUR(sv) = phs-alen;
*SvEND(sv) = '\0';
if (debug = 2)
***
*** 1395,1400
--- 1416,1432
bufsv = SvRV(destrv);
sv_setpvn(bufsv,,0);/* ensure it's writable string */
+
+ #ifdef OCI_V8_SYNTAX
+ #ifdef UTF8_SUPPORT
+ if (ftype == 112 cs_is_utf8) {
+ return ora_blob_read_mb_piece(sth, imp_sth, fbh, bufsv,
+ offset, len, destoffset);
+ }
+
+ #endif /* UTF8_SUPPORT */
+ #endif /* ifdef OCI_V8_SYNTAX */
+
SvGROW(bufsv, destoffset+len+1); /* SvGROW doesn't do +1 */
#ifdef OCI_V8_SYNTAX
*** //c/usr/local/src/DBD-Oracle-1.03//./dbdimp.h Mon Jul 12 05:21:12 1999
--- ./dbdimp.h Thu May 04 12:55:12 2000
***
*** 236,241
--- 236,245
extern int ora_fetchtest;
+ #ifdef UTF8_SUPPORT
+ extern int cs_is_utf8;
+ #endif
+
void dbd_init_oci _((dbistate_t *dbistate));
void dbd_preparse _((imp_sth_t *imp_sth, char *statement));
void dbd_fbh_dump _((imp_fbh_t *fbh, int i, int aidx));
*** //c/usr/local/src/DBD-Oracle-1.03//./Makefile.PLMon Jul 12 05:21:14 1999
--- ./Makefile.PL Tue May 09 11:00:51 2000
***
*** 162,168
elsif (($os eq 'MSWin32') or ($os =~ /cygwin/i)) {
my $oci_compiler_dir = ($Config{cc} eq 'bcc32' ? BORLAND : MSVC);
! my $OCIDIR = ;
find( sub {
print Found $_ directory\n if /^OCI\d+/i;
$OCIDIR = $_ if /^OCI\d\d+$/i $OCIDIR lt $_;
--- 162,168
elsif (($os eq 'MSWin32') or ($os =~ /cygwin/i)) {
my $oci_compiler_dir = ($Config{cc} eq 'bcc32' ? BORLAND : MSVC);
! my $OCIDIR = OCI;
CGI::Carp cluck problem with Apache 2.0.40
Has anyone else been using Perl/DBI with Apache 2.0.XX for cgi applications? If you have, have you had problems with print STDERR blah going to the apache error log? I'm sure a related problem is the inability of cluck messages to hit the error log. Has anyone else experienced similar problems? Is this a problem with Apache, or ??? Thanks. -- Hardy Merrill Senior Software Engineer Red Hat, Inc.
fetchall_arrayref(): large amounts of data
I'm downloading several million records from an Oracle database to a MySql database and would like to use fetchall_arrayref() to do it. However, there are so many records that my computer memory fills up and then crashes. Is there a way of chunking the data coming down or do I need to use the fetch_arrayref() and do it one record at a time (several million times)? Thanks, Phil
Re: AnyData Conversion
I'm very interested in the new DBD::AnyData as I use it to work with CSV
files in conjunction with DBI::PurePerl. Does the new version that's
in the works have any speed/resource/architecture improvements? I
thought it was mentioned previously that it would be revised based on
lessons learned while working on DBI::PurePerl. Or am I thinking of
the pending (if there is a pending) SQL::Statement revisions? Just
curious - thanks for a great module.
I'd be glad to beta the new version and/or do some hi res timer
comparisons if needed. Please let me know if I can help at all.
Nick Hendler
[EMAIL PROTECTED]
_
From:Jeff Zucker [EMAIL PROTECTED]
Date:Thursday, October 3, 2002
Time:10:41:36 PM
Subject: AnyData Conversion (Was Re: Uploaded to CPAN: DBIx::Dump)
Sterin, Ilya wrote:
That would be fine. I was thinking in terms of supporting data formats that
can't be queried,
Yes, there are already some like that, for example one can query Mp3
file embedded text tags, but not create or modify them.
AnyData.pm, I haven't looked at the source,
Don't :-). Look at the development version which is migrating to a
dispatch_method similar to DBI::PurePerl (which is part of why it's
taking me so long for the next release).
I'm not sure if Jeff wants to
add these misceleneous data structures.
The more the merrier. Users have developed task-specific AnyData
parsers for things like genomes and sun-flare reports. See the list
below for a half dozen other general formats developed by other authors.
I just added an event driven interface to DBIx::Dump, which allows to define
event handlers and due on the fly transformations/formatting before
outputting. Not sure about the AnyData interface and if it will allow for
such additions without much reprogramming.
On the contrary, there is support already for both post-read and
pre-write event handlers in the development version of the module as
well as support for on-the-fly user-defined parsers.
Jeff???
Yes, Ilya, let's collaborate!!!
Here's what adConvert will look like in the next release (90% of it is
available in the current version):
adConvert({
data_source = $filename
| *file_handle
| $http_url
| $ftp_url
| [$string]
| [DATA]
| $array_of_arrays
| $array_of_hashes
| $dbi_database_handle
| $dbi_query_statement_handle,
data_target = $filename
| *file_handle
| $dbi_insert_statement_handle,
| undef (returns a string, AoA,or AoH
depending on the specified target
format)
source_format = CSV
| Tab
| Pipe
| Space
| Ini
| XML
| DBI
| Fixed (with Doug Wilson)
| SNMP (by Wes Hardaker)
| Excel (by Kawai, Takinori)
| Syslog(by Tod Harter)
| MLDBM (in progress, with Brian Hann)
| HTMLtable
| Storable
| Passwd
| Weblog
| Mbox (anyone want to collaborate or take
on this one?)
| AoA
| AoH
| FileSys
| Mp3
| Usr (user-defined)
| $your_format_here (please submit format parsers
the next release will have an
actual API for them)
target_format = (same as source formats except for Mp3)
flags = (various flags, most with defaults
to determine method of finding colnames;
set a file_locking mechanism if needed,
set delimiter, separator, quote and escape chars;
define pre-write and post-read handler routines)
});
Re: Which shared memory module to use?
On Monday, October 14, 2002, at 01:10 PM, Michael Peppler wrote: On Fri, 2002-10-11 at 14:27, Henri Asseily wrote: Regarding what I've dubbed DBIx::HA, here's the idea: There hasn't been up to now (or at least I haven't found any) a widely available Perl/DBI-based system for system architects who handle high-availability groups of servers, either in read-only load-balanced mode or read-write hot-backup mode. Oracle, Sybase and others do offer high-availability options, but they cost upward of $30,000 for a single implementation. In addition, I tested Sybase's OpenSwitch which does not cooperate properly with DBI, but that's a story for another day. That's almost certainly an issue with DBD::Sybase. It's probably not handling (or passing) the proper connection attributes (at the C / Sybase API level). I agree. The behavior we saw was that DBD would talk to openswitch and get a properly working database handle, but when/if the db server died and/or openswitch would change the active server to another one, the dbh would be in a bad state, be dead and still point to the unavailable server. Somehow when openswitch does the handshake, DBD::Sybase takes it and goes straight to the db server that is pointed at. The only way right now to fix it is to ping the connect, and if unavailable, disconnect and reconnect. Henri.
RE: Bug in DBD-ODBC 0.45_16
Sorry this has taken so long to respond to.
-Original Message-
From: Roger Perttu [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 03, 2002 12:01 PM
To: [EMAIL PROTECTED]
Subject: Re: Bug in DBD-ODBC 0.45_16
Jeff,
I've been busy but finally managed to test the new version. It still
fails my test.
Sigh .. . here's the test I used (at the bottom) -- isn't that what you
sent?
Jeff Urlwin wrote:
Roger,
I've finally had a chance to look at this (going through my
queue of issues
questions). What I can see is the following:
- No result columns are being returned
In my case there isn't a query running.
Right.
- DBD::ODBC calls SQLMoreResults (and gets
SQL_SUCCESS_WITH_INFO) to skip
over the empty result set
- There are no more results, so execute() returns
- then, the call to NUM_OF_FIELDS triggers a describe
By describe you mean SQLDescribeCol, right? Where does the parameter
value come from? I'm calling the procedure with the parameter set to -1
(which doesn't produce a resultset) but SQLDescribeCol uses 0 which does
produce a resultset. (See the SQL Profiler text below)
Why does the call to NUM_OF_FIELDS trigger a describe? Doesn't the call
to execute provide the necesarry information?
No, the execute doesn't (at least I don't think it does). SQLExecute
returns success or failure, not the number or type of columns.
Copied from BOL:
For executed statements, the Microsoft® SQL Server ODBC driver does not
need to query the server to describe columns in a result set. In this
case, SQLDescribeCol does not cause a server roundtrip.
That just means that the ODBC driver (the SQL Server part) knows about the
query, without needing to re-query the database. At somepoint, probably
right after the execute or during prepare, where the result set doesn't
change or is predictable, it *must* retrieve something about the result set.
The current implementation seems like a huge performance hog.
It may be :), but after execute, DBD::ODBC must determine the right columns.
Especially in the case where stored procs can return varying result sets (in
your example one input can produce a select * from blah in the other, return
@1...
- to that, SQLServer returns a large description of columns
(probably
describing what would be the select * from systypes would have been.
I would have thought it would not return anything at that point,
other than
there are no rows in the result set.
I've fixed the problem/worked around it. My tests pass here, but it's
probably worth you testing further.
Thanks for the find and the test! I'm releasing _18 tonight.
Thanks for the update. Strange it didn't fix my problem. I rebooted my
machine to make sure I wasn't using the old dll. I might have done some
stupid error but ppm says I'm using 0.45_18. (Is there a way to see
which version of the dll (not the module) Perl is using when the program
is running?)
Just check the date. Or, untar the .tar.gz file and check the .dll in the
blib/* directory.
May I see your test for this specific case? I couldn't (easily) find it
in http://search.cpan.org/src/JURL/DBD-ODBC-0.45_18/
attached. It's in a private test area, where I didn't include it in the
tarball.
I've managed to produce a test case for the bug I reported earlier.
When I call a stored procedure that should not return data
$sth-{NUM_OF_FIELDS} is wrong and I get the following error:
E:\Projekt\Helpdesk\Perl\UpgradeDBdbitest4.pl
$sth-{NUM_OF_FIELDS}: 18 expected: 0
DBD::ODBC::st fetchrow_hashref failed: (DBD: no select statement
currently executing err=-1) [for statement ``{call testPrc(?)}'' with
params: 1=-1]) at
E:\Projekt\Helpdesk\Perl\UpgradeDB\DbiTest4.pl line 47.
The problem is caused by the fact that the procedure is called with
different parameters when its output is examined (SET FMTONLY ON).
Cut and paste from SQL Profiler:
Event Class Text
+Connect
+ExistingConnection
+SQL:BatchStartingset implicit_transactions on
+RPC:Starting testPrc -1
+SP:Starting testPrc
+SP:StmtStarting if(@parameter1 = 0)
+SP:StmtStarting RETURN(@parameter1)
+SP:Completed testPrc
+SQL:BatchStartingSET FMTONLY ON EXEC testPrc 0 SET FMTONLY OFF
+SP:Starting testPrc
+SP:StmtStarting if(@parameter1 = 0)
+SP:StmtStarting select * from systypes
+SP:StmtStarting RETURN(@parameter1)
+SP:Completed testPrc
+SQL:BatchStartingIF @@TRANCOUNT 0 ROLLBACK TRAN
Disconnect
Cerate the testPrc procedure first and edit %options before you run.
= Dbitest4.pl
use strict;
use warnings;
use DBI;
use constant LONG_READ_LEN = 8000;
my %options = (
DbSrcServer = '(local)',
DbSrcDatabase = 'databaseName',
DbSrcLoginName = 'sa',
DbSrcPassword = '',
);
my @dbhPool;
##
### Functions
RE: Bug in DBD-ODBC 0.45_18
Are you saying the wrong value is getting posted to the procedure?
Jeff
-Original Message-
From: Roger Perttu [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 8:47 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Bug in DBD-ODBC 0.45_18
This is for the most part a repost of my earlier post Bug in DBD-ODBC
0.45_16
I've now tested it (DBD-ODBC 0.45_18) on a fresh install of W2k and
Active Perl 633. Even three different MDAC's 2.5 sp2, 2.6 sp2 and 2.7
RTM sp2. AFIK the bug is still there.
The problem is that my sp is called with the wrong parameter value in (0
instead of -1):
SET FMTONLY ON EXEC testPrc 0 SET FMTONLY OFF
Just for testing I changed the default value from 0 to -1 but
that didn't have any effect.
I then added a new parameter to the procedure to see if describe
would use two parameters but it didn't.
Finally I changed my test script to use two parameters and the
procedure is now called with both parameters wrong.
/Roger P
Original Message
Subject: Re: Bug in DBD-ODBC 0.45_16
Date: Thu, 03 Oct 2002 18:01:20 +0200
From: Roger Perttu [EMAIL PROTECTED]
Organization: Easit AB
To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Jeff,
I've been busy but finally managed to test the new version. It still
fails my test.
Jeff Urlwin wrote:
Roger,
I've finally had a chance to look at this (going through my
queue of issues
questions). What I can see is the following:
- No result columns are being returned
In my case there isn't a query running.
- DBD::ODBC calls SQLMoreResults (and gets
SQL_SUCCESS_WITH_INFO) to skip
over the empty result set
- There are no more results, so execute() returns
- then, the call to NUM_OF_FIELDS triggers a describe
By describe you mean SQLDescribeCol, right? Where does the parameter
value come from? I'm calling the procedure with the parameter set to -1
(which doesn't produce a resultset) but SQLDescribeCol uses 0 which does
produce a resultset. (See the SQL Profiler text below)
Why does the call to NUM_OF_FIELDS trigger a describe? Doesn't the call
to execute provide the necesarry information?
Copied from BOL:
For executed statements, the Microsoft® SQL Server ODBC driver does not
need to query the server to describe columns in a result set. In this
case, SQLDescribeCol does not cause a server roundtrip.
The current implementation seems like a huge performance hog.
- to that, SQLServer returns a large description of columns
(probably
describing what would be the select * from systypes would have been.
I would have thought it would not return anything at that point,
other than
there are no rows in the result set.
I've fixed the problem/worked around it. My tests pass here, but it's
probably worth you testing further.
Thanks for the find and the test! I'm releasing _18 tonight.
Thanks for the update. Strange it didn't fix my problem. I rebooted my
machine to make sure I wasn't using the old dll. I might have done some
stupid error but ppm says I'm using 0.45_18. (Is there a way to see
which version of the dll (not the module) Perl is using when the program
is running?)
May I see your test for this specific case? I couldn't (easily) find it
in http://search.cpan.org/src/JURL/DBD-ODBC-0.45_18/
Regards,
Jeff
Hi,
I've managed to produce a test case for the bug I reported earlier.
When I call a stored procedure that should not return data
$sth-{NUM_OF_FIELDS} is wrong and I get the following error:
E:\Projekt\Helpdesk\Perl\UpgradeDBdbitest4.pl
$sth-{NUM_OF_FIELDS}: 18 expected: 0
DBD::ODBC::st fetchrow_hashref failed: (DBD: no select statement
currently executing err=-1) [for statement ``{call testPrc(?)}'' with
params: 1=-1]) at
E:\Projekt\Helpdesk\Perl\UpgradeDB\DbiTest4.pl line 47.
The problem is caused by the fact that the procedure is called with
different parameters when its output is examined (SET FMTONLY ON).
Cut and paste from SQL Profiler:
Event Class Text
+Connect
+ExistingConnection
+SQL:BatchStartingset implicit_transactions on
+RPC:Starting testPrc -1
+SP:Starting testPrc
+SP:StmtStarting if(@parameter1 = 0)
+SP:StmtStarting RETURN(@parameter1)
+SP:Completed testPrc
+SQL:BatchStartingSET FMTONLY ON EXEC testPrc 0 SET FMTONLY OFF
+SP:Starting testPrc
+SP:StmtStarting if(@parameter1 = 0)
+SP:StmtStarting select * from systypes
+SP:StmtStarting RETURN(@parameter1)
+SP:Completed testPrc
+SQL:BatchStartingIF @@TRANCOUNT 0 ROLLBACK TRAN
Disconnect
Cerate the testPrc procedure first and edit %options before you run.
= Dbitest4.pl
use strict;
use warnings;
use DBI;
use constant LONG_READ_LEN = 8000;
my %options = (
DbSrcServer = '(local)',
DbSrcDatabase = 'databaseName',
DbSrcLoginName = 'sa',
