RE: Oracle 10.1.0.2, RedHat AS, and DBD::Oracle
The DBD::Oracle module requires some things to build which are not included in the client version (it generates code using certain headers and example files which are part of the full install). Note that these files are only required to compile it. Running it should only require libclntsh.so and the usual oracle networking which is present if you can connect via sqlplus. You have two options: 1.) Grab a binary from somewhere 2.) compile it on a box with these other components (perhaps your rdbms server?) and then copy it to the app server box. -Original Message- From: Jim Spath [mailto:[EMAIL PROTECTED] Sent: 20 July 2004 16:24 To: [EMAIL PROTECTED] Subject: Oracle 10.1.0.2, RedHat AS, and DBD::Oracle We got a fancy new RedHat AS server here at work, and our Sys Admin installed the Oracle 10.1.0.2 client on it (although the Oracle server is running version Oracle8i Release 8.1.7.4.0). SQL*Plus seems to work fine for connecting to our Oracle servers, despite the version difference. I was attempting to install DBD::Oracle on this machine and, as you might expect, ran into a few problems. I guess my first question is: Should I even try to install DBD::Oracle (v 1.15) with Oracle 10.1.0.2 on RedHat AS? My sense of the situation is that this version of Oracle is too recent for DBD::Oracle, and I would prefer _not_ to make hacks/tweaks that are out of the ordinary to get it to work. If DBD::Oracle can work with Oracle 10.1.0.2, how exactly do I go about installing it? My problem is that it says my ORACLE_HOME is not valid, even though I can run SQL*Plus. If DBD::Oracle cannot work with Oracle 10.1.0.2, what version of DBD::Oracle and Oracle would you guys recommend? Remember I am running on RedHat AS w/ Perl 5.8.0 (although we may upgrade to 5.8.5 soon). Thanks in advance to anyone who answers! - Jim __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. The contents are confidential and may be privileged. Any views or opinions expressed are those of the sender and may not reflect the views or opinions of the company and the company accepts no liability in respect thereof. If you have received this email in error please notify [EMAIL PROTECTED] immediately. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
DBD::Proxy Setting DBH attributes.
I am asking a question, that I'm pretty sure I know the answer to, but
just in case I am missing something,
The following example code works,
use DBI;
my $dbh = DBI-connect('dbi:Oracle:sid', 'user', 'password', {});
$dbh-{FetchHashKeyName} = 'NAME_lc';
my $res = $dbh-selectall_hashref(q{
Select id, name, sum
From foo
}, 'id');
...if I use DBD::PROXY the setting of 'FetchHashKeyName' does not work.
I did see this in DBD::Proxy perldocs,
KNOWN ISSUES
Complex handle attributes
Sometimes handles are having complex attributes like hash refs or
array
refs and not simple strings or integers. For example, with
DBD::CSV,
you would like to write something like
$dbh-{csv_tables}-{passwd} =
{ sep_char = :, eol = \n;
...but I did not think that FetchHashKeyName is a complex attribute..
Am I missing something(probably)?
Thanks,
STH
[Fwd: DBD::Proxy Setting DBH attributes.]
Tried sending this yesterday, and it never showed up on the list.
Trying again...
-Forwarded Message-
From: Scott T. Hildreth [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Subject: DBD::Proxy Setting DBH attributes.
Date: Tue, 20 Jul 2004 16:39:21 -0500
I am asking a question, that I'm pretty sure I know the answer to, but
just in case I am missing something,
The following example code works,
use DBI;
my $dbh = DBI-connect('dbi:Oracle:sid', 'user', 'password', {});
$dbh-{FetchHashKeyName} = 'NAME_lc';
my $res = $dbh-selectall_hashref(q{
Select id, name, sum
From foo
}, 'id');
...if I use DBD::PROXY the setting of 'FetchHashKeyName' does not work.
I did see this in DBD::Proxy perldocs,
KNOWN ISSUES
Complex handle attributes
Sometimes handles are having complex attributes like hash refs or
array
refs and not simple strings or integers. For example, with
DBD::CSV,
you would like to write something like
$dbh-{csv_tables}-{passwd} =
{ sep_char = :, eol = \n;
...but I did not think that FetchHashKeyName is a complex attribute..
Am I missing something(probably)?
Thanks,
STH
Re: dbi-dbd on solaris w/installed perl
Hi Mickey, I had a quite similar problem, but I had also to build a 64bit perl because we're using 64bit informix. So I compiled perl 5.8.0 and installed it under /usr/per5/5.8.0. Works great. You will not be able to build any perl add on without Sun CC because perl Makefile.PL will create a Makefile that uses the compiler that compiled perl. You could download the sun compiler and use it with the 60 day trial license. regards Thomas -- General Logistics Systems Thomas Mieslinger German-Parcel-Str. 1-7 fon: +49 6677 17 463 36286 Neuenstein fax: +49 6677 17 111 GermanyeMail: [EMAIL PROTECTED] Mickey Mestel [EMAIL PROTECTED] schrieb am 21.07.2004 22:25:03: hi, it has been a number of years since i have made and installed the dbi, and i'm at it again. platform: solaris 9 on sparc, dbi 1.34, dbd informix 2003.03.0401, gcc 2.95.3, perl 5.8.4. problem is that with the stock perl, (which is 5.6.1), while with some tweaking, i can get things to compile and test reasonably ok. but it is explicit in the README that perl, dbi and dbd should all be compiled with the same compiler. i've also read that there can be issues with replacing the standard perl that comes with solaris. things compile and run great when i start from scratch, but that means replacing the existing perl that shipped with solaris. my one thought was to simply install it under a different path, and set my path to point to that when i want to use the dbi. any other thoughts? i'm sure this has been encountered before.. thanks, mickm
Re: DBD::Sybase message suppression....
From: amonotod [EMAIL PROTECTED]
Date: 2004/07/21 Wed PM 10:12:45 GMT
From: Chuck Fox [EMAIL PROTECTED]
Date: 2004/07/21 Wed PM 09:35:55 GMT
Install an error handler, ignore messages with a severity of 0 or 10
Okay, found that... Will try it out soonest...
Basically, straight out of the docs...
if (\U$servers{$server}-{type}\E eq SYBASE) {
$dbh-{syb_err_handler} = \err_handler;
}
sub err_handler {
my($err, $sev, $state, $line, $server, $proc, $msg, $sql, $err_type) = @_;
my @msg = ();
if (($sev != 0) ($sev != 10)) {
if($err_type eq 'server') {
push @msg, ('', 'Server message',
sprintf('Message number: %ld, Severity %ld, State %ld, Line %ld',
$err,$sev,$state,$line),
(defined($server) ? Server '$server' : '') .
(defined($proc) ? Procedure '$proc' : ''),
Message String:$msg);
} else {
push @msg, ('', 'Open Client Message:',
sprintf('Message number: SEVERITY = (%ld) NUMBER = (%ld)', $sev, $err),
Message String: $msg);
}
print STDERR join(\n,@msg);
return 0; ## CS_SUCCEED
}
}
Thanks again,
amonotod
--
`\|||/ amonotod@| sun|perl|windows
(@@) charter.net | sysadmin|dba
ooO_(_)_Ooo
_|_|_|_|_|_|_|_|
Re: DBD::Sybase message suppression....
From: amonotod [EMAIL PROTECTED] Date: 2004/07/22 Thu PM 02:10:13 GMT } print STDERR join(\n,@msg); return 0; ## CS_SUCCEED } } Actually, that's wrong. It should be this... } print STDERR join(\n,@msg); } return 0; ## CS_SUCCEED } Why? We need to return a status amonotod -- `\|||/ amonotod@| sun|perl|windows (@@) charter.net | sysadmin|dba ooO_(_)_Ooo _|_|_|_|_|_|_|_|
DBI and unicode seg. fault
Hi,
I have mysql with iso-latin2 support, DBI 1.32 and perl 5.8.0.
The code below causes segmentation fault of perl when $DBI::errstr
contains an iso-latin2 character(s). What I have wrong?
--test.pl-
#!/usr/bin/perl
use encoding 'latin2';
use open :std,
IN = :encoding(iso-8859-2),
OUT = :encoding(iso-8859-2);
require DBI;
$SQL = DBI-connect(DBI:mysql:test);
# character in the select statement is 'a' with 'caron'
my $sql = $SQL-prepare(Encode::encode('iso-8859-2',select ));
$sql-execute;
if ($DBI::errstr) {
return 0;
}
--
$ DBI_TRACE=2 perl test.pl
DBI 1.32-ithread dispatch trace level set to 2
- DBI-connect(DBI:mysql:test, , )
- DBI-install_driver(mysql) for linux perl=5.008 pid=29285 ruid=500
euid=500
install_driver: DBD::mysql version 2.0419 loaded from
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/DBD/mysql.pm
- install_driver= DBI::dr=HASH(0x82a5e3c)
- default_user in DBD::_::dr for DBD::mysql::dr
(DBI::dr=HASH(0x82a5e3c)~0x8303834 undef undef HASH(0x827c074))
thr#815a058
- default_user= ( undef undef ) [2 items] at DBI.pm line 510
- connect for DBD::mysql::dr (DBI::dr=HASH(0x82a5e3c)~0x8303834
'test' undef HASH(0x827c074)) thr#815a058
imp_dbh-connect: dsn = test, uid = , pwd =
imp_dbh-MyLogin: dbname = test, uid = NULL, pwd = NULL,host = NULL, port
= NULL
imp_dbh-MyConnect: host = NULL, port = 0, uid = NULL, pwd = NULL
imp_dbh-MyConnect: client_flags = 0
- connect= DBI::db=HASH(0x8303804) at DBI.pm line 513
- STORE for DBD::mysql::db (DBI::db=HASH(0x830381c)~INNER
'PrintError' 1) thr#815a058
- STORE= 1 at DBI.pm line 555
- STORE for DBD::mysql::db (DBI::db=HASH(0x830381c)~INNER
'AutoCommit' 1) thr#815a058
- STORE= 1 at DBI.pm line 555
- connect= DBI::db=HASH(0x8303804)
Segmentation fault
--
Ondrej Koala Vacha
Fix for problems installing DBD::mysql-2.9004 with mysql-4.0.20
Perl-5.8.5 compiled happily, now updating DBD::mysql with: mysql-standard-4.0.20-pc-linux-i686 DBD-mysql-2.9004 Catch is that newer mysql distro's use ./lib and ./include for their files not ./lib/mysql or ./include/mysql. Fix is to symlink '.' to mysql in the lib directory and use an explicit '-I' with the cflags. For example: $ perl Makefile.PL I will use the following settings for compiling and testing: cflags(mysql_config) = -I/usr/local/mysql/include/mysql -mcpu=pentiumpro libs (mysql_config) = -L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lc -lnss_files -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv nocatchstderr (default ) = 0 nofoundrows (default ) = 0 ssl (guessed ) = 0 testdb(default ) = test testhost (default ) = testpassword (default ) = testuser (default ) = To change these settings, see 'perl Makefile.PL --help' and 'perldoc INSTALL'. Note (probably harmless): No library found for -lmysqlclient Using DBI 1.43 (for perl 5.008005 on i686-linux-thread-multi) installed in /opt/perl/5.8/lib/site_perl/5.8.4/i686-linux-thread-multi/auto/DBI Writing Makefile for DBD::mysql EH??? No libmysqlclient? $ find /usr/local/mysql/ -name 'libmysqlclient*' -follow /usr/local/mysql/lib/libmysqlclient.a /usr/local/mysql/lib/libmysqlclient_r.a One hak fixes it: cd /usr/local/mysql/lib; ln -fs . mysql; Now I get: cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm cp lib/Mysql.pm blib/lib/Mysql.pm cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod cp lib/Mysql/Statement.pm blib/lib/Mysql/Statement.pm cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm /opt/gcc/bin/gcc -c -I/opt/perl/5.8/lib/site_perl/5.8.4/i686-linux-thread-multi/auto/DBI -I/usr/local/mysql/include/mys ql -mcpu=pentiumpro -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FIL E_OFFSET_BITS=64 -I/usr/include/gdbm -O3 -march=pentium4 -DVERSION=\2.9004\ -DXS_VERSION=\2.9004\ -fpic -I/opt/pe rl/5.8/lib/5.8.5/i686-linux-thread-multi/CORE dbdimp.c `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. In file included from dbdimp.c:19: dbdimp.h:21:49: mysql.h: No such file or directory dbdimp.h:22:49: errmsg.h: No such file or directory In file included from dbdimp.c:19: dbdimp.h:106: error: parse error before MYSQL dbdimp.h:106: warning: no semicolon at end of struct or union dbdimp.h:117: error: parse error before '}' token dbdimp.h:146: error: parse error before MYSQL_RES dbdimp.h:146: warning: no semicolon at end of struct or union dbdimp.h:159: error: parse error before '}' token In file included from dbdimp.c:19: snip Which was fixed via: perl Makefile.PL --cflags='-O3 -march=i686 -I/usr/local/mysql/include'; -- Steven Lembark 9 Music Square South, Box 344 Workhorse ComputingNashville, TN 37203 [EMAIL PROTECTED] 1 888 359 3508
Issue with SQL statement
Title: Issue with SQL statement Hi, I am attempting an insert with dates and I am getting the following: /* INSERT into MASTER_Entry VALUES (?,?,?,?,?,?,?) with values E1138132263904 Javier Moreno has become the new Systems Engineer for AMS. 2004-07-22 00:00:00 H B 3018525 2004-04-19 00:00:00 [Oracle][ODBC][Ora]ORA-01861: literal does not match format string (SQL-HY000)(DBD: st_execute/SQLExecute err=-1) */ Of course the first error message is from my application which basically outputs the values I am trying to insert. What I did also was insert manually in the database and then retrieve from it to see if I could find out what was wrong with my date format. From that SELECT I found out apparently I needed the hour as well so I corrected my insert accordingly. I have checked all other fieds and they fall within the needed length. Could you please advise? Regards, Javier Moreno Systems Engineer - Transmissions When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth - Sherlock Holmes
RE: Issue with SQL statement
From oerr: 01861, 0, literal does not match format string // *Cause: Literals in the input must be the same length as literals in // the format string (with the exception of leading whitespace). If the // FX modifier has been toggled on, the literal must match exactly, // with no extra whitespace. // *Action: Correct the format string to match the literal. What is your NLS_DATE_FORMAT for the session trying to perform this insert? -- Ron Reidy Sr. DBA Array BioPharma, Inc. -Original Message- From: Moreno, Javier [mailto:[EMAIL PROTECTED] Sent: Thu 7/22/2004 12:46 PM To: [EMAIL PROTECTED] Cc: Subject:Issue with SQL statement Hi, I am attempting an insert with dates and I am getting the following: /* INSERT into MASTER_Entry VALUES (?,?,?,?,?,?,?) with values E1138132263904 Javier Moreno has become the new Systems Engineer for AMS. 2004-07-22 00:00:00 H B 3018525 2004-04-19 00:00:00 [Oracle][ODBC][Ora]ORA-01861: literal does not match format string (SQL-HY000)(DBD: st_execute/SQLExecute err=-1) */ Of course the first error message is from my application which basically outputs the values I am trying to insert. What I did also was insert manually in the database and then retrieve from it to see if I could find out what was wrong with my date format. From that SELECT I found out apparently I needed the hour as well so I corrected my insert accordingly. I have checked all other fieds and they fall within the needed length. Could you please advise? Regards, Javier Moreno ole0.bmp Systems Engineer - Transmissions When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth - Sherlock Holmes This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system. attachment: ole0.bmp
(Fwd) yes/no question
- Forwarded message from Andreas Vieli [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] X-Pobox-Antispam: Require PTR Record returned DENY: 195.141.50.99 has no PTR record X-SPF-Guess: pass (seems reasonable for [EMAIL PROTECTED] to mail through 195.141.50.99) From: Andreas Vieli [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: yes/no question Date: Thu, 22 Jul 2004 09:13:58 +0200 X-warpgate.ch-MailScanner-Information: Please contact the ISP for more information X-warpgate.ch-MailScanner: Found to be clean X-warpgate.ch-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.7, required 5, BAYES_00 -4.90, HTML_70_80 0.10, HTML_MESSAGE 0.10) hi WinXP Prof., Oracle 9.2.0.1.0, latest Cygwin, Perl 5.8.2, oracle DBI-1.43, DBD-Oracle-1.15 does that work at all (I have some troubles...) best regards andy - End forwarded message -
Re: Oracle 10.1.0.2, RedHat AS, and DBD::Oracle
On Tue, Jul 20, 2004 at 03:56:48PM -0400, Jim Spath wrote: Thanks for the input everyone. You are right Tim, it turned out the Sys Admin had only installed the Instant Client. Once we used the developer install, everything worked out OK. Should I be able to install with the instant client only? Not yet. I believe Oracle are working on fixing this (they'll be an SDK add-on to Instant Client). Tim. What made me think that DBD::Oracle 1.15 would not work (or would need a hack) was this post: http://groups.google.com/groups?q=DBD::Oracle+1.15+oracle+10g+linux+twea khl=enlr=ie=UTF-8safe=offselm=aofi20lvmogulfe3o8kabf3g6meenj560u%40 4ax.comrnum=1 But now that I look at it, it seems to simply be a suggestion for improving the install process. Thanks again! - Jim -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 3:33 PM To: Jim Spath Cc: [EMAIL PROTECTED] Subject: Re: Oracle 10.1.0.2, RedHat AS, and DBD::Oracle On Tue, Jul 20, 2004 at 11:24:02AM -0400, Jim Spath wrote: We got a fancy new RedHat AS server here at work, and our Sys Admin installed the Oracle 10.1.0.2 client on it (although the Oracle server is running version Oracle8i Release 8.1.7.4.0). SQL*Plus seems to work fine for connecting to our Oracle servers, despite the version difference. I was attempting to install DBD::Oracle on this machine and, as you might expect, ran into a few problems. I guess my first question is: Should I even try to install DBD::Oracle (v 1.15) with Oracle 10.1.0.2 on RedHat AS? My sense of the situation is that this version of Oracle is too recent for DBD::Oracle, and I would prefer _not_ to make hacks/tweaks that are out of the ordinary to get it to work. If DBD::Oracle can work with Oracle 10.1.0.2, how exactly do I go about installing it? My problem is that it says my ORACLE_HOME is not valid, even though I can run SQL*Plus. Sounds like it's using the new Oracle Instant Client. Should work fine. You can ignore (disable) the ORACLE_HOME error. You may need to 'fiddle around' a bit but we can't help more without specific information (see the README for what we'd need). Tim.
Re: DBI and unicode seg. fault
On Thu, Jul 22, 2004 at 05:12:57PM +0200, Ondrej Koala Vacha wrote:
Hi,
I have mysql with iso-latin2 support, DBI 1.32 and perl 5.8.0.
The code below causes segmentation fault of perl when $DBI::errstr
contains an iso-latin2 character(s). What I have wrong?
--test.pl-
#!/usr/bin/perl
use encoding 'latin2';
use open :std,
IN = :encoding(iso-8859-2),
OUT = :encoding(iso-8859-2);
require DBI;
$SQL = DBI-connect(DBI:mysql:test);
# character in the select statement is 'a' with 'caron'
my $sql = $SQL-prepare(Encode::encode('iso-8859-2',select á));
$sql-execute;
if ($DBI::errstr) {
return 0;
}
--
$ DBI_TRACE=2 perl test.pl
- connect= DBI::db=HASH(0x8303804)
Segmentation fault
The trace shows that the connect() method has returned but the prepare()
method has not been entered. The segmentation fault is probably from
Encode::encode().
Tim.
Segmentation fault in test 02simple.t
Hi all,
The make test fails in 02simple.t with a segmentation fault.
The DBI version is 1.43
The DBD::ODBC version I'm trying to install is 1.09
The platform is AIX 5.2 compiling with cc_r
The perl version is 5.8.4 (see below for the -V output)
The DSN points to a SQL Server database.
The segmentation fault occurs in the test 02simple.t at the iteration 19 (Test 19:
test connection success when DBI DSN is invalid)
After some tracing I could spot the problem in the function dbd_db_login6, line 447
while evaluating the statement:
if (!imp_drh-connects) {
I could check that the values of imp_drh is not null, so probably the pointer
references an invalid memory address. I didn't dare to troubleshoot further...
Is there any suggestion for the next step in finding the problem?
Fred
Output from the test:
bash-2.01# perl -I blib/lib -I blib/arch t/02simple.t
1..21
ok 1
Test 2: connecting to the database
ok 2
Test 3: create test table
Using fields: COL_A smallint NOT NULL PRIMARY KEY , COL_B varchar(8000), COL_C text,
COL_D datetime
ok 3
Test 4: check existance of test table
(unknown owner).PERL_DBD_TEST
ok 4
Test 5: insert test data
ok 5
Test 6: select test data
1|foo|foo varchar|
2|bar|bar varchar|
3|bletch|bletch varchar|
4|80char|THIS IS A STRING LONGER THAN 80 CHARS. THIS SHOULD BE CHECKED FOR TRUNCATION
AND COMPARED WITH ITSELF.|
5|gt250char|THIS IS A STRING LONGER THAN 80 CHARS. THIS SHOULD BE CHECKED FOR
TRUNCATION AND COMPARED WITH ITSELF. THIS IS A STRING LONGER THAN 80 CHARS. THIS
SHOULD BE CHECKED FOR TRUNCATION AND COMPARED WITH ITSELF. THIS IS A STRING LONGER
THAN 80 CHARS. THIS SHOULD BE CHECKED FOR TRUNCATION AND COMPARED WITH ITSELF. THIS
IS A STRING LONGER THAN 80 CHARS. THIS SHOULD BE CHECKED FOR TRUNCATION AND COMPARED
WITH ITSELF.|
retrieved 103 byte string OK
retrieved 418 byte string OK
ok 6
Tests 7,8: test LongTruncOk
ok 7
ok 8
Test 9: test ColAttributes
Column count is: 4
1: COL_A = 5 5 yes
2: COL_B = 12 12 yes
3: COL_C = -1 -1 yes
4: COL_D = 93 93 yes
ok 9
Test 10: test $DBI::err
ok 10
Test 11: test date or timestamp values
1998-05-14 00:00:00.000
ok 11
Test 12: test group by queries
1, 1
2, 1
3, 1
4, 1
5, 1
ok 12
Test 13: test data_sources
Data sources:
DBI:ODBC:BUILD_DB
ok 13
Test 14: test ping method
ok 14
Test 15: test storing of DBH parameter
ok 15
Attrib not true (1)
Test 16: test connecting twice to the same db.
ok 16
Test 17: test get_info
connected to Microsoft SQL Server
ok 17
Test 18: test automatically finish when execute run again
ok 18
Test 19: test connection success when DBI DSN is invalid
Segmentation fault (core dumped)
Perl version:
bash-2.01# perl -V
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=aix, osvers=5.2.0.0, archname=aix-thread-multi
uname='aix nestine 2 5 002526bd4c00 '
config_args=''
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_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1
-qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32 -D_LARGE_FILES -qlonglong',
optimize='-O',
cppflags=''
ccversion='6.0.0.0', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld', ldflags =' -brtl -L/usr/local/lib -b32'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lbind -lnsl -ldbm -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd
perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd
libc=/lib/libc.a, so=a, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-bE:/usr/local/lib/perl5/5.8.4/aix-thread-multi/CORE/perl.exp'
cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE -bI:$(PERL_INC)/perl.exp
-bE:$(BASEEXT).exp -bnoentry -lpthreads -lc -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under aix
Compiled at Jul 22 2004 12:42:42
@INC:
/usr/local/lib/perl5/5.8.4/aix-thread-multi
/usr/local/lib/perl5/5.8.4
/usr/local/lib/perl5/site_perl/5.8.4/aix-thread-multi
/usr/local/lib/perl5/site_perl/5.8.4
/usr/local/lib/perl5/site_perl
.
Re: DBI and unicode seg. fault
On Thu, 22 Jul 2004, Tim Bunce wrote: The trace shows that the connect() method has returned but the prepare() method has not been entered. The segmentation fault is probably from Encode::encode(). No, the example generated a sql query: 040722 23:07:17 218 Connect [EMAIL PROTECTED] on test 218 Query select Encode::encode works fine. I have found one solution: in open.pm comment two binmode commands, lines 133+134: # binmode(STDOUT, :$1); # binmode(STDERR, :$1); I don't know why :( -- Ondrej Koala Vacha
Re: Fix for problems installing DBD::mysql-2.9004 with mysql-4.0.20
Steven, which OS, version is this? I'd be glad to test this out and find out what the fix is. Did you get DBD::mysql from cpan? thanks much! Patrick Steven Lembark wrote: Perl-5.8.5 compiled happily, now updating DBD::mysql with: mysql-standard-4.0.20-pc-linux-i686 DBD-mysql-2.9004 Catch is that newer mysql distro's use ./lib and ./include for their files not ./lib/mysql or ./include/mysql. Fix is to symlink '.' to mysql in the lib directory and use an explicit '-I' with the cflags. For example: $ perl Makefile.PL I will use the following settings for compiling and testing: cflags(mysql_config) = -I/usr/local/mysql/include/mysql -mcpu=pentiumpro libs (mysql_config) = -L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lc -lnss_files -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv nocatchstderr (default ) = 0 nofoundrows (default ) = 0 ssl (guessed ) = 0 testdb(default ) = test testhost (default ) = testpassword (default ) = testuser (default ) = To change these settings, see 'perl Makefile.PL --help' and 'perldoc INSTALL'. Note (probably harmless): No library found for -lmysqlclient Using DBI 1.43 (for perl 5.008005 on i686-linux-thread-multi) installed in /opt/perl/5.8/lib/site_perl/5.8.4/i686-linux-thread-multi/auto/DBI Writing Makefile for DBD::mysql EH??? No libmysqlclient? $ find /usr/local/mysql/ -name 'libmysqlclient*' -follow /usr/local/mysql/lib/libmysqlclient.a /usr/local/mysql/lib/libmysqlclient_r.a One hak fixes it: cd /usr/local/mysql/lib; ln -fs . mysql; Now I get: cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm cp lib/Mysql.pm blib/lib/Mysql.pm cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod cp lib/Mysql/Statement.pm blib/lib/Mysql/Statement.pm cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm /opt/gcc/bin/gcc -c -I/opt/perl/5.8/lib/site_perl/5.8.4/i686-linux-thread-multi/auto/DBI -I/usr/local/mysql/include/mys ql -mcpu=pentiumpro -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FIL E_OFFSET_BITS=64 -I/usr/include/gdbm -O3 -march=pentium4 -DVERSION=\2.9004\ -DXS_VERSION=\2.9004\ -fpic -I/opt/pe rl/5.8/lib/5.8.5/i686-linux-thread-multi/CORE dbdimp.c `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. In file included from dbdimp.c:19: dbdimp.h:21:49: mysql.h: No such file or directory dbdimp.h:22:49: errmsg.h: No such file or directory In file included from dbdimp.c:19: dbdimp.h:106: error: parse error before MYSQL dbdimp.h:106: warning: no semicolon at end of struct or union dbdimp.h:117: error: parse error before '}' token dbdimp.h:146: error: parse error before MYSQL_RES dbdimp.h:146: warning: no semicolon at end of struct or union dbdimp.h:159: error: parse error before '}' token In file included from dbdimp.c:19: snip Which was fixed via: perl Makefile.PL --cflags='-O3 -march=i686 -I/usr/local/mysql/include'; -- Patrick Galbraith, Senior Systems Engineer MySQL AB, www.mysql.com Office: +1 206 719 2461 Are you MySQL certified? www.mysql.com/certification
DBD::Oracle for Oracle 9i versoin 9.2.0 (64 bit Oracle)
I am unable to compile/build DBD::Oracle with Oracle 9i (64-bit Oracle RDBMS) library. Could someone please help? Thanks. regards surjit This message contains information from Equifax Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail [EMAIL PROTECTED]
Re: DBI and unicode seg. fault
On Thu, Jul 22, 2004 at 11:13:21PM +0200, Ondrej Koala Vacha wrote: On Thu, 22 Jul 2004, Tim Bunce wrote: The trace shows that the connect() method has returned but the prepare() method has not been entered. The segmentation fault is probably from Encode::encode(). No, the example generated a sql query: 040722 23:07:17 218 Connect [EMAIL PROTECTED] on test 218 Query select á Encode::encode works fine. I have found one solution: in open.pm comment two binmode commands, lines 133+134: # binmode(STDOUT, :$1); # binmode(STDERR, :$1); I don't know why :( Please try to isolate the problem further. A stack trace from the core file would be a _big_ help. Try using http://search.cpan.org/search%3fmodule=Devel::CoreStack Reproducing it without the DBI, if possible, would also help. Tim.
Re: DBD::Oracle for Oracle 9i versoin 9.2.0 (64 bit Oracle)
On Thu, Jul 22, 2004 at 05:14:03PM -0400, [EMAIL PROTECTED] wrote: I am unable to compile/build DBD::Oracle with Oracle 9i (64-bit Oracle RDBMS) library. Could someone please help? Thanks. http://homepage.eircom.net/~timbunce/DBD-Oracle-1.16-rc5-20040715.tar.gz http://www.catb.org/~esr/faqs/smart-questions.html Tim.
DBD::Oracle binary release for AS Perl NON announcement (was RE: :Oracle 1.16 question)
I see the files under the FTP but there is one set that says: DBD-Oracle9-1.16-5.8.3.tar.gz Is that the same as the file that says: DBD-Oracle-1.16-5.8.3.tar.gz I ask because I am using Oracle9 and so if there is something specific to it that would be good to know. Sigh. You weren't supposed to see that :) That's an experimental version and I didn't want to make it public. Leave it alone for now, as it's got a problem (a PREREQ_PM dependancy on Test::More, but there is *no* package Test-More, it's named Test-Simple. Therefore, PPM doesn't find it. Don't go near it and I will take it down for the moment to avoid issues. But, to answer your question, you should install DBD-Oracle9.ppd from that site if you have a 9i client (or above). You should install DBD-Oracle if you have an 8i client. The line of thinking is that there are enough people out there with the 8i client. The 9i build won't run on most = 8i client installs due to the lack of OCILobWriteAppend() in versions less than 8.1.[67] Jeff
RE: Segmentation fault in test 02simple.t
Hi all,
The make test fails in 02simple.t with a segmentation fault.
The DBI version is 1.43
The DBD::ODBC version I'm trying to install is 1.09
The platform is AIX 5.2 compiling with cc_r
The perl version is 5.8.4 (see below for the -V output)
The DSN points to a SQL Server database.
The segmentation fault occurs in the test 02simple.t at the
iteration 19 (Test 19: test connection success when DBI DSN
is invalid)
After some tracing I could spot the problem in the function
dbd_db_login6, line 447 while evaluating the statement:
if (!imp_drh-connects) {
I could check that the values of imp_drh is not null, so
probably the pointer references an invalid memory address. I
didn't dare to troubleshoot further...
Is there any suggestion for the next step in finding the problem?
Yes: which driver manager are you using (unixODBC, iODBC)? (I'm not sure
that matters, but would like to know)
Hmm...you only get as far as imp_drh-connects? imp_drh is created by DBI,
so I'd be concerned that either prior tests have a memory leak/overrun or
something else is wrong.
Do the rest of the tests run fine?
Can you run a test or two of your own where you cut down the tests in that
file and add them back until it repeats? (i.e. smallest possible
reproduction case?)
Jeff
Fred
Output from the test:
bash-2.01# perl -I blib/lib -I blib/arch t/02simple.t
1..21
ok 1
Test 2: connecting to the database
ok 2
Test 3: create test table
Using fields: COL_A smallint NOT NULL PRIMARY KEY , COL_B
varchar(8000), COL_C text, COL_D datetime ok 3 Test 4: check
existance of test table (unknown owner).PERL_DBD_TEST ok 4
Test 5: insert test data ok 5 Test 6: select test data
1|foo|foo varchar|
2|bar|bar varchar|
3|bletch|bletch varchar|
4|80char|THIS IS A STRING LONGER THAN 80 CHARS. THIS SHOULD
BE CHECKED
4|80char|FOR TRUNCATION AND COMPARED WITH ITSELF.|
5|gt250char|THIS IS A STRING LONGER THAN 80 CHARS. THIS SHOULD BE
5|gt250char|CHECKED FOR TRUNCATION AND COMPARED WITH ITSELF.
THIS IS A STRING LONGER THAN 80 CHARS. THIS SHOULD BE
CHECKED FOR TRUNCATION AND COMPARED WITH ITSELF. THIS IS A
STRING LONGER THAN 80 CHARS. THIS SHOULD BE CHECKED FOR
TRUNCATION AND COMPARED WITH ITSELF. THIS IS A STRING LONGER
THAN 80 CHARS. THIS SHOULD BE CHECKED FOR TRUNCATION AND
COMPARED WITH ITSELF.|
retrieved 103 byte string OK
retrieved 418 byte string OK
ok 6
Tests 7,8: test LongTruncOk
ok 7
ok 8
Test 9: test ColAttributes
Column count is: 4
1: COL_A = 5 5 yes
2: COL_B = 12 12 yes
3: COL_C = -1 -1 yes
4: COL_D = 93 93 yes
ok 9
Test 10: test $DBI::err
ok 10
Test 11: test date or timestamp values
1998-05-14 00:00:00.000
ok 11
Test 12: test group by queries
1, 1
2, 1
3, 1
4, 1
5, 1
ok 12
Test 13: test data_sources
Data sources:
DBI:ODBC:BUILD_DB
ok 13
Test 14: test ping method
ok 14
Test 15: test storing of DBH parameter
ok 15
Attrib not true (1)
Test 16: test connecting twice to the same db.
ok 16
Test 17: test get_info
connected to Microsoft SQL Server
ok 17
Test 18: test automatically finish when execute run again
ok 18
Test 19: test connection success when DBI DSN is invalid
Segmentation fault (core dumped)
Perl version:
bash-2.01# perl -V
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=aix, osvers=5.2.0.0, archname=aix-thread-multi
uname='aix nestine 2 5 002526bd4c00 '
config_args=''
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_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE
-D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN
-DNEED_PTHREAD_INIT -q32 -D_LARGE_FILES -qlonglong',
optimize='-O',
cppflags=''
ccversion='6.0.0.0', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld', ldflags =' -brtl -L/usr/local/lib -b32'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lbind -lnsl -ldbm -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd
perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd
libc=/lib/libc.a, so=a, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-bE:/usr/local/lib/perl5/5.8.4/aix-thread-multi/CORE/perl.exp'
cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE
-bI:$(PERL_INC)/perl.exp
Re: dbi-dbd on solaris w/installed perl (DBI 1.34 is broken w.r.t DBD::Informix - ancient news)
Mickey Mestel wrote: it has been a number of years since i have made and installed the dbi, and i'm at it again. platform: solaris 9 on sparc, dbi 1.34, dbd informix 2003.03.0401, gcc 2.95.3, perl 5.8.4. problem is that with the stock perl, (which is 5.6.1), while with some tweaking, i can get things to compile and test reasonably ok. but it is explicit in the README that perl, dbi and dbd should all be compiled with the same compiler. i've also read that there can be issues with replacing the standard perl that comes with solaris. things compile and run great when i start from scratch, but that means replacing the existing perl that shipped with solaris. my one thought was to simply install it under a different path, and set my path to point to that when i want to use the dbi. any other thoughts? i'm sure this has been encountered before.. I've already responded separately to Mickey from the office, but had better make sure the news group knows the answer too. I did have some extra information to help with the diagnosis: this is the output of the make: /tmp/mickm/perl5/bin/perl /tmp/mickm/perl5/lib/5.8.4/ExtUtils/xsubpp -typemap /tmp/mickm/perl5/lib/5.8.4/ExtUtils/typemap Informix.xs Informix.xsc mv Informix.xsc Informix.c gcc -c -I/opt/informix/incl/esql -I/tmp/mickm/perl5/lib/5.8.4/sun4-solaris/auto/DBI -I/tmp/mickm/perl5/lib/site_perl/5.8.4/sun4-solaris/auto/DBI -I/auto/DBI -I/tmp/mickm/perl5/lib/site_perl/5.8.4/sun4-solaris/auto/DBI -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\2003.03.0401\ -DXS_VERSION=\2003.03.0401\ -fPIC -I/tmp/mickm/perl5/lib/5.8.4/sun4-solaris/CORE -DESQLC_VERSION=953 -DNDEBUG Informix.c Informix.xsi: In function `XS_DBD__Informix__dr_data_sources': Informix.xsi:56: parse error before `*' Informix.xsi:58: `av' undeclared (first use in this function) Informix.xsi:58: (Each undeclared identifier is reported only once Informix.xsi:58: for each function it appears in.) Informix.xsi:58: `imp_drh' undeclared (first use in this function) *** Error code 1 make: Fatal error: Command failed for target `Informix.o' OK - I remember what this problem is, now I've rebuilt DBI 1.34 for Perl 5.8.4 and then tried your version of DBD::Informix (and had it pass!!!). I'm using GCC 3.4.1, and it follows ISO C:1999 and permits declarations anywhere in a function, unlike GCC 2.95.3. And that's the trouble. At line 100 of Informix.c, you'd find a declaration D_imp_drh(drh); aftersome code. So, what's the fix? The code in Informix.xs in 2003.04 is identical with the code in 2003.03.0401, so the change must be in DBI -- it's a bit of template copied from DBI. And the Changes file for DBI (1.42 happens to be the version I'm looking at) says under DBI 1.35 Fixed to ANSI C in dbd_dr_data_sources thanks to Jonathan Leffler. Please upgrade your DBI - v1.35 is minimum, 1.43 is recommended. -- Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include disclaimer.h Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
