Re: DBI setup problem
That's no DBI issue.
You have to declare the variable $dbh using my, local or our before using
it. Example:
my $dbh = DBI-connect(...
Alternatively you could omit -w, use warnings and use strict to make
your script run without special variable declarations.
Hendrik
Am Mi, 9.06.2010, 00:13, schrieb r...@gandalf.ws:
I am running Ubuntu 10.04 LTS and perl, v5.10.1.
I am attempting to test perl access to a mysql database with the following
code:
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI;
my($USAGE) = $0 DUMMY\n\n;
unless(@ARGV) { die $USAGE; }
$dbh = DBI-connect('DBI:mysql:friends', 'rich', 'MarySue'
) || die Could not connect to
database: $DBI::errstr;
# (insert querys here...)
$dbh-disconnect();
When executed the program produces the following results:
r...@rich-desktop:~/Documents/perl/friends$ ./email01.pl
Global symbol $dbh requires explicit package name at ./email01.pl line
23.
Global symbol $dbh requires explicit package name at ./email01.pl line
26.
Execution of ./email01.pl aborted due to compilation errors.
r...@rich-desktop:~/Documents/perl/friends$
What am I doing wrong?
Rich Price r...@gandalf.ws
The optimist thinks that this is the best of
all possible worlds. The pessimist knows it.
J. Robert Oppenheimer
Re: How to suss out module dependencies...
A crude solution would be to print the contents of %INC somewhere in your application: perl -e 'use DBI; use Time::Local; print join (\n, keys %INC);' Am Do, 27.05.2010, 22:41, schrieb C. Chad Wallace: At 2:53 PM on 27 May 2010, William Bulley wrote: I have a Perl application that uses many Perl modules. Most come from CPAN, some I have written, others come with Perl distributions (core?). I am faced with the need to transport this collection of Perl code from operating system A to operating system B, both of which are perfectly well supported by Perl. Over several months I have added to system A lots of modules that need other modules. Unfortunately, system B is rather devoid of most of the modules that I need for this application. I dread having to make an inclusive list of all the modules and all the modules that those modules need, and so on, and so on. The autobundle command of CPAN would give you a bundle file that lists of all the modules you've installed on system A. Then you can take that bundle file over to system B and install it using CPAN. Your bundle may end up with a lot of extra modules that your program doesn't need, but you can edit the bundle file and remove them. Or maybe you could see if you can get a profiler (like Devel::NYTProf) to tell you which modules are loaded when you load and run your module. -- C. Chad Wallace, B.Sc. The Lodging Company http://www.lodgingcompany.com/ OpenPGP Public Key ID: 0x262208A0
Re: sigtrap disabled after DBI-connect
use sigtrap is probably executed at compile time and thus before the
connect regardless of its location in the source code. You could try if
your signal handler works during the readline if you set $SIG{'INT'} =
'SigExit'; (same for HUP and KILL) after the connect.
Hendrik
Am Di, 2.03.2010, 21:36, schrieb Steve Lynn:
On Mar 2, 2:30am, martin.ev...@easysoft.com (Martin Evans) wrote:
Lynn, Steve wrote:
All - I'm under Solaris using perl v. 5.8.3 and DBI v. 1.48. I can
catch signals w/o a problem before I connect to the database.
However after I connect, I can't catch signals anymore. If I comment
out the DBI-connect and press ctrl-c in a ReadLine(0), the signal
is caught fine.
I found one other issue that seemed similar
(http://www.mail-archive.com/dbi-us...@perl.org/msg07747.html).
Please help.
###
#!/usr/local/perl -w
use strict;
use warnings;
use Term:ReadKey;
require DBI;
use sigtrap 'handler', \SigExit, qw/HUP INT KILL/;
my $dbh;
my $response;
sub SigExit {
print STDOUT \nTest\n;
die(\n);
}
$dbh =
DBI-connect(DBI:Oracle:host=dbserver;sid=mydb;port=1521,scott,tiger);
print \nEnter a response: ;
$response = ReadLine(0);
print \nEnter another response: ;
$response = ReadLine(0);
###
Thanks,
Steve
Oracle client libraries can trap some signals (including HUP) depending
on which ones you use and how you are connecting. I believe you will
need to set up your handlers after connect for those signals but I
cannot remember the down side in Oracle.
There have been various posts on dbi-users about this in the past so an
archive of dbi-users (some can be found at dbi.perl.org) would probably
list them.
Martin
--
Martin J. Evans
Easysoft Limitedhttp://www.easysoft.com- Hide quoted text -
- Show quoted text -
Thanks Martin.
I'm not sure whether I was clear enough on my goal. I'm trying to
trap INT signals so that when requesting input from the operator with
ReadLine, they can press ctrl-c and exit. I don't like the default
signal handling so I'd like to just do a die(\n) when an INT is
received.
When I comment out the DBI-connect, a ctrl-c will exit from the
ReadLine as intended. However, once the DBI-connect is completed,
and the operator presses ctrl-c within the ReadLine, '^C' appears, but
the signal handler isn't called. It looks like the DBI-connect
cancels, disables or overrides my sigtrap.
I'm not trying to handle any signals from within DBI. I just trying
to handle INT from within ReadLine. It seems like DBI-connect is
canceling my signal handler.
I tried to reload sigtrap immediately after the DBI-connect but that
didn't work either:
#!/usr/local/perl -w
use strict;
use warnings;
use Term:ReadKey;
require DBI;
use sigtrap 'handler', \SigExit, qw/HUP INT KILL/;
my $dbh;
my $response;
sub SigExit {
print STDOUT \nTest\n;
die(\n);
}
$dbh = DBI-
connect(DBI:Oracle:host=dbserver;sid=mydb;port=1521,scott,tiger);
use sigtrap 'handler', \SigExit, qw/HUP INT KILL/;
print \nEnter a response: ;
$response = ReadLine(0);
print \nEnter another response: ;
$response = ReadLine(0);
##
Any help would be appreciated,
Steve Lynn
Re: DBI-1.609 installation problem in perl 5.8.4 on OS Solaris
make tells you: sh: cc: not found So you need the cc compiler to build DBI. Its either not there at all or not in your path. It should be the same compiler that was used to build perl. In case you dont have it you may build perl AND dbi with another compiler. Am Mi, 2.12.2009, 13:31, schrieb Mostafizur Rahman: Dear All, I am getting an while installing DBI-1.609 in perl 5.8.4. when enter command make following error occurs, # /usr/ccs/bin/make cc -c -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff -DVERSION=\1.609\ -DXS_VERSION=\1.609\ -KPIC -I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE -DDBI_NO_THREADS Perl.c sh: cc: not found *** Error code 1 make: Fatal error: Command failed for target `Perl.o' My perl version is as below. #perl -V Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=solaris, osvers=2.10, archname=sun4-solaris-64int uname='sunos localhost 5.10 sun4u sparc SUNW,Ultra-2' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERR NO', optimize='-xO3 -xspace -xildoff', cppflags='' ccversion='Sun WorkShop', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize =8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags ='' libpth=/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /usr/perl5/5.8.4/lib /sun4-solaris-64int/CORE' cccdlflags='-KPIC', lddlflags='-G' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: 22667 The optree builder was looping when constructing the ops ... 22715 Upgrade to FileCache 1.04 22733 Missing copyright in the README. 22746 fix a coredump caused by rv2gv not fully converting a PV ... 22755 Fix 29149 - another UTF8 cache bug hit by substr. 22774 [perl #28938] split could leave an array without ... 22775 [perl #29127] scalar delete of empty slice returned garbage 22776 [perl #28986] perl -e open m crashes Perl 22777 add test for change #22776 (open m crashes Perl) 22778 add test for change #22746 ([perl #29102] Crash on assign ... 22781 [perl #29340] Bizarre copy of ARRAY make sure a pad op's ... 22796 [perl #29346] Double warning for int(undef) and abs(undef) ... 22818 BOM-marked and (BOMless) UTF-16 scripts not working 22823 [perl #29581] glob() misses a lot of matches 22827 Smoke [5.9.2] 22818 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu) 22830 [perl #29637] Thread creation time is hypersensitive 22831 improve hashing algorithm for ptr tables in perl_clone: ... 22839 [perl #29790] Optimization busted: '@a = b, sort @a' ... 22850 [PATCH] 'perl -v' fails if local_patches contains code snippets 22852 TEST needs to ignore SCM files 22886 Pod::Find should ignore SCM files and dirs 22888 Remove redundant %SIG assignments from FileCache 23006 [perl #30509] use encoding and eq cause memory leak 23074 Segfault using HTML::Entities 23106 Numeric comparison operators mustn't compare addresses of ... 23320 [perl #30066] Memory leak in nested shared data structures ... 23321 [perl #31459] Bug in read() Built under solaris Compiled at Jan 21 2005 15:27:47 @INC: /usr/perl5/5.8.4/lib/sun4-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_perl/5.8.4/sun4-solaris-64int /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int /usr/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl # uname -a SunOS inmssvr4 5.10 Generic sun4u sparc SUNW,Sun-Fire Can any one please help me. Thanks Mohammad Mostafizur Rahman Net.Admin
Re: DBD::ODBC and character sets
Correct. I shouldn't answer before reading everything. :/
Am Di, 29.09.2009, 17:03, schrieb Martin Evans:
Hendrik Schumacher wrote:
At the first glance you may be using a non-unicode database connection.
In
this case
$dbh-do (set names 'utf8');
may help.
Hendrik
Are you sure that is a SQL Server 2008 statement? I thought that was a
mysql thing.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Am Di, 29.09.2009, 16:39, schrieb Stephan Austermühle:
Hi all,
maybe I do not to see the wood for the trees...
All I want to do is to process strings with special characters (e.g.,
Umlauts), i.e. INSERT and SELECT them from my database (SQL
Server 2008).
Querying strings with special characters works fine now:
$ locale |grep ^LC_CTYPE
LC_CTYPE=en_US.UTF-8
Perl code:
binmode(STDIN, ':utf8');
binmode(STDOUT, ':utf8');
binmode(STDERR, ':utf8');
...
$st = $dbh-prepare(q/SELECT id, name FROM foo/);
$st-execute() || croak(Cannot SELECT);
while (my $r = $st-fetchrow_hashref()) {
printf(%3d %s\n, $r-{'id'}, $r-{'name'});
}
$dbh-commit();
Result:
1 Gänz vüle Ã*mläute und Ã*eugs
Okay, SELECTing works (unless use encoding 'utf8' is given).
Now the other way. Insert a row and fill a column with a string
containing
special characters:
$st = $dbh-prepare(q/INSERT INTO foo (name) VALUES (?)/);
$st-execute(süÃ*) || croak(Cannot INSERT);
$dbh-commit();
...
Result: Column 'name' is empty (but not NULL). Tracing shows
Unicode login6
dbname=DSN=XXX;MARS_Connection=Yes, uid='XXX', pwd=XXX
Now using dbname = DSN=XXX;MARS_Connection=Yes;UID=XXX;PWD=XXX;
SQLDriverConnect 'DSN=XXX;MARS_Connection=Yes;UID=XXX;PWD=XXX;',
''XXX'', 'XXX'
Out connection string: DSN=XXX;MARS_Connection=Yes;UID=XXX;PWD=XXX;
Turning autocommit on
DRIVER_ODBC_VER = 03.00
DRIVER_NAME = libtdsodbc.so
DRIVER_VERSION = 0.82.1.dev.20090904
MAX_COLUMN_NAME_LEN = 128
DBD::ODBC is unicode built : YES
Deferring Binding
SQL_DBMS_NAME = Microsoft SQL Server
SQLMoreResults supported: 1
SQLDescribeParam supported: 0
SQLDescribeParam supported: 0
unicode support = 1
Processing non-utf8 sql in unicode mode
Processing non-utf8 sql in unicode mode
Can you give me a hint how to handle special characters with Perl and
DBD::ODBC?
Setup:
- Perl 5.8.9
- FreeTDS v0.82.1.dev.20090904 (Unicode build)
- unixODBC 2.2.14
- DBD::ODBC 1.23 (Unicode build)
Thanks and regards,
Stephan
RE: DBI connect and ports issue
Just an idea:
You raise an alarm when DBD::Oracle/OCI takes too long waiting for a
connection. If you just quit the connection attempt then, OCI may never
have a chance to clean up its connection attempt (especially the opened
UDP port).
Am Do, 15.01.2009, 04:01, schrieb Martin Gainty:
Jaya-
Port 1526 sounds odd as the default port for oracle is 1521
Anyone see anything obvious?
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official
business of Sender. This transmission is of a confidential nature and
Sender does not endorse distribution to any party other than intended
recipient. Sender does not necessarily endorse content contained within
this transmission.
Subject: DBI connect and ports issue
Date: Wed, 14 Jan 2009 16:31:12 -0500
From: jaya.megh...@vonage.com
To: dbi-users@perl.org
Hi,
My first post too the list!
First some environment details:
Red Hat Enterprise Linux WS release 4 (Nahant Update 4)
Perl Version = 5.008007
DBI Version = 1.48
DBD::Oracle Version = 1.16
Issue:
My application connects to Oracle and some times the DB host is down. I
use sigaction to put a timeout on DBI-connect and retry again till
connection is established.
The problem is: I see a lot of unused ports for the application process.
1). TCP ports in CLOSE_WAIT and ESTABLISHED states.
2). Ephemeral UDP ports.
These ports accumulate over time as DB connection is lost and
re-established.
I use lsof and netstat commands to check the stats on ports.
To reproduce the issue I have this script (see below), I don't see any
TCP ports waiting in CLOSE_WAIT and ESTABLISHED states but each time the
script tries to connect (and is timed-out) a new ephemeral UDP port is
created.
I use iptables to DROP any packets to DB host to simulate DB host down
scenario.
**
Output:
Here is the output of script and Port stats:
$perl sigTry.perl
I am in handler
Trying to connect
Error connecting to DB
I out of handler
Hit Return key
I am in handler
Trying to connect
Error connecting to DB
I out of handler
Hit Return key
I am in handler
Trying to connect
Error connecting to DB
I out of handler
#Command to see ports stats
$lsof -p `pgrep perl` | egrep TCP|UDP
perl28572 jmeghani4u IPv4 2132909 UDP
localhost:33544
perl28572 jmeghani5u IPv4 2132913 TCP host1:33466-
someDBhost:1526 (SYN_SENT)
perl28572 jmeghani7u IPv4 2132924 UDP
localhost:33545
perl28572 jmeghani8u IPv4 2132926 TCP host1-
someDBhost:1526 (SYN_SENT)
perl28572 jmeghani 10u IPv4 2132927 UDP
localhost:33546
perl28572 jmeghani 11u IPv4 2132929 TCP
host1:33468-someDBhost:1526 (SYN_SENT)
SYN_SENT ports go away with time but UDP ports (33544-33546) don't.
**
Finally actual script (I have removed actual DB details)
Script:
**
$ENV{ORACLE_HOME} = '/usr/vendor/pkg/oracle/product/10.2.0';
use strict;
use warnings;
use POSIX;
use DBI;
my $db_hostname = 'someDBhost';
my $db_port = 1526;
my $db_user = 'test';
my $db_pass = 'test';
my $db_sid = 'SID';
my $dbh = undef;
sub finished {
print I am outta here\n;
exit(1);
}
sub handler {
print I am in handler\n;
if (!defined($dbh)) {
print Trying to connect\n;
my $old_action = POSIX::SigAction-new();
my $action = POSIX::SigAction-new( sub{die 'TIMEOUT';
});
sigaction(SIGALRM,$action, $old_action);
my $old_t;
eval {
sigprocmask(SIG_UNBLOCK,
POSIX::SigSet-new(SIGALRM));
$old_t = alarm(2);
$dbh =
DBI-connect(dbi:Oracle:host=$db_hostname;sid=$db_sid;port=$db_port,
$db_user, $db_pass,
{PrintError = 0, RaiseError = 1,
AutoCommit = 0});
alarm(0);
print I am connected\n;
};
alarm(0);
sigaction(SIGALRM, $old_action);
alarm($old_t);
if ($@) {
if(defined($dbh)){
print dbh was defined\n;
$dbh=undef;
}
print(Error connecting to DB\n);
}
}
else {
print Already connected\n;
}
print I out of handler\n;
}
sub main {
my $action_die = POSIX::SigAction-new(\finished);
Re: trouble installing DBD:Oracle on linux
Hi Harsha.
Sorry for my generic first reply but I only found time to look at your
Makefile output in detail now.
There may be an issue with 32 bit/64 bit (the Makefile uses a build rule
rather than build64) but thats probably not your issue.
Your Makefile run seems to be successful. Did you try to make DBD:Oracle?
Did it build? Did any tests fail? If no tests failed you are likely good
to go.
The warning you obviously refer to only affects one way DBD::Oracle uses
to discover the build rules:
WARNING: Oracle build rule discovery failed (512)
Oracle oci build command:
[]
WARNING: Unable to interpret Oracle build commands from
/usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk.
(Will continue by using fallback approach.)
Please report this to dbi-us...@perl.org. See README for what to
include.
As I wrote in my first message I dont have any experience with DBD::Oracle
but from the Makefile I would say this message is harmless if DBD::Oracle
builds without problems AND your Oracle doesnt use any uncommon build
rules.
The Makefile runs a make command and uses the output to determine the
build rules. The error code 512 simply means that make encountered an
error but its impossible to tell which one. If you wanted to find out, you
could replay the steps of the Makefile being:
1. Create a temporary directory
2. Create a file DBD_ORA_OBJ.c there with the following content:
int main() { return 1; }
3. Run:
make DBD_ORA_OBJ.o CC=cc
4. Run:
make -f /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk
build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=true OPTIMIZE=
CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o
The last command should give an error message.
Hendrik
Am Sa, 10.01.2009, 19:50, schrieb Harsha Hegde:
Thanks for the response, Hendrik. What libraries should I look for?
LD_LIBRARY_PATH has the following files:
r...@devserver-165:~# echo $LD_LIBRARY_PATH
/usr/vendor/pkg/oracle/product/10.2.0/lib
r...@devserver-165:~# cd $LD_LIBRARY_PATH
r...@devserver-165:/usr/vendor/pkg/oracle/product/10.2.0/lib# ls
libclntsh.so libnnz10.solibocci.so libocijdbc10.so
sysliblist
libclntsh.so.10.1 libocci10_296.so.10.1 libocci.so.10.1 libsqlplus.so
Thanks,
On Fri, Jan 9, 2009 at 4:37 PM, Hendrik Schumacher
h...@activeframe.dewrote:
Am Fr, 9.01.2009, 16:43, schrieb Harsha Hegde:
Hi DBI users,
I am trying to install DBD::Oracle on a x86 64bit machine running
Ubuntu
Linux. I see the following error:
r...@devserver-165:~/.cpan/build/DBD-Oracle-1.22-4sDScg# perl
Makefile.PL
Using DBI 1.607 (for perl 5.01 on x86_64-linux) installed in
/usr/local/lib/perl5/site_perl/5.10.0/x86_64-linux/auto/DBI/
Configuring DBD::Oracle for perl 5.01 on linux (x86_64-linux)
Remember to actually *READ* the README file! Especially if you have
any
problems.
Installing on a linux, Ver#2.6
Using Oracle in /usr/vendor/pkg/oracle/product/10.2.0
DEFINE _SQLPLUS_RELEASE = 1002000100 (CHAR)
Oracle version 10.2.0.1 (10.2)
Found /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk
Found /usr/vendor/pkg/oracle/product/10.2.0/rdbms/lib/ins_rdbms.mk
Using /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk
Your LD_LIBRARY_PATH env var is set to
'/usr/vendor/pkg/oracle/product/10.2.0/lib'
Reading /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk
Reading /usr/vendor/pkg/oracle/product/10.2.0/rdbms/lib/env_rdbms.mk
Attempting to discover Oracle OCI build rules
cc-c -o DBD_ORA_OBJ.o DBD_ORA_OBJ.c
by executing: [make -f
/usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/
demo_rdbms.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh'
CC=true
OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o]
WARNING: Oracle build rule discovery failed (512)
Oracle oci build command:
[]
WARNING: Unable to interpret Oracle build commands from
/usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk.
(Will continue by using fallback approach.)
Please report this to dbi-us...@perl.org. See README for what to
include.
Found header files in
/usr/vendor/pkg/oracle/product/10.2.0/rdbms/public.
Checking for functioning wait.ph
System: perl5.01 linux
devserver-165.dev.s.vonagenetworks.net2.6.20-17-generic #2 smp wed jul
9 22:24:42 utc 2008 x86_64 gnulinux
Compiler: cc -O2 -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
Linker: /usr/bin/ld
Sysliblist: -ldl -lm -lpthread -lnsl -lirc
Oracle makefiles would have used these definitions but we override
them:
CC: cc
CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\
$(SHARED_CFLAG) $(USRFLAGS)
[$(GFLAG) -O3 $(CDEBUG) -m32 $(TRIGRAPHS_CCFLAGS) -fPIC
-I/usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo
-I/usr/vendor/pkg/oracle/product/10.2.0/rdbms/public
-I/usr
Re: DBD problem with knowing where Oracle is at.
Am Fr, 9.01.2009, 21:40, schrieb Bruce Johnson: On Jan 9, 2009, at 1:19 PM, Kong, Alan wrote: Chris, The LD_LIBRARY_PATH, LD_RUN_PATH, and SHLIB_PATH are normally set to $ORACLE_HOME/lib or $ORACLE_HOME/lib32 for 32 bit database depend on where your lib files located. But from your first email, it set to the same value as $ORACLE_HOME. Change the settings and see if it's working. His settings are normal for Oracle Instant Client, which has everything dumped into a single directory. Chris, is this running in a web server? Apache lets you get environment variables from the environment of the user starting the httpd process, usually root. I think I ran into something similar when I was setting up our new server a while back. I had to put a directive into the httpd.conf file: PassEnv LD_LIBRARY_PATH with the appropriate settings. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs This reply should be spot-on. I remember someone had the same issue in this list a while ago and the correct environment just wasnt set inside apache. If the script runs from the command line and doesnt somewhere else its almost always to do with the environment setup. The same should apply to the script run by cron. Either set the environment like Bruce suggested or run your script inside a wrapper shell script thats used to set the needed env vars. Hendrik
Re: trouble installing DBD:Oracle on linux
Am Fr, 9.01.2009, 16:43, schrieb Harsha Hegde: Hi DBI users, I am trying to install DBD::Oracle on a x86 64bit machine running Ubuntu Linux. I see the following error: r...@devserver-165:~/.cpan/build/DBD-Oracle-1.22-4sDScg# perl Makefile.PL Using DBI 1.607 (for perl 5.01 on x86_64-linux) installed in /usr/local/lib/perl5/site_perl/5.10.0/x86_64-linux/auto/DBI/ Configuring DBD::Oracle for perl 5.01 on linux (x86_64-linux) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a linux, Ver#2.6 Using Oracle in /usr/vendor/pkg/oracle/product/10.2.0 DEFINE _SQLPLUS_RELEASE = 1002000100 (CHAR) Oracle version 10.2.0.1 (10.2) Found /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk Found /usr/vendor/pkg/oracle/product/10.2.0/rdbms/lib/ins_rdbms.mk Using /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk Your LD_LIBRARY_PATH env var is set to '/usr/vendor/pkg/oracle/product/10.2.0/lib' Reading /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk Reading /usr/vendor/pkg/oracle/product/10.2.0/rdbms/lib/env_rdbms.mk Attempting to discover Oracle OCI build rules cc-c -o DBD_ORA_OBJ.o DBD_ORA_OBJ.c by executing: [make -f /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/ demo_rdbms.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=true OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o] WARNING: Oracle build rule discovery failed (512) Oracle oci build command: [] WARNING: Unable to interpret Oracle build commands from /usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo/demo_rdbms.mk. (Will continue by using fallback approach.) Please report this to dbi-us...@perl.org. See README for what to include. Found header files in /usr/vendor/pkg/oracle/product/10.2.0/rdbms/public. Checking for functioning wait.ph System: perl5.01 linux devserver-165.dev.s.vonagenetworks.net2.6.20-17-generic #2 smp wed jul 9 22:24:42 utc 2008 x86_64 gnulinux Compiler: cc -O2 -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Linker: /usr/bin/ld Sysliblist: -ldl -lm -lpthread -lnsl -lirc Oracle makefiles would have used these definitions but we override them: CC: cc CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -O3 $(CDEBUG) -m32 $(TRIGRAPHS_CCFLAGS) -fPIC -I/usr/vendor/pkg/oracle/product/10.2.0/rdbms/demo -I/usr/vendor/pkg/oracle/product/10.2.0/rdbms/public -I/usr/vendor/pkg/oracle/product/10.2.0/plsql/public -I/usr/vendor/pkg/oracle/product/10.2.0/network/public -DLINUX -D_GNU_SOURCE -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE_SOURCE=1 -DSLTS_ENABLE -DSLMXMX_ENABLE -D_REENTRANT -DNS_THREADS -fno-strict-aliasing $(LPFLAGS) $(USRFLAGS)] build: $(CC) $(ORALIBPATH) -o $(EXE) $(OBJS) $(OCISHAREDLIBS) [ cc -L$(LIBHOME) -L/usr/vendor/pkg/oracle/product/10.2.0/rdbms/lib/ -o $(EXE) $(OBJS) -lclntsh $(EXPDLIBS) $(EXOSLIBS) -ldl -lm -lpthread -lnsl -lirc -ldl -lm $(USRLIBS) -lpthread] LDFLAGS: $(LDFLAGS32) [-m32 -o $@ -L/usr/vendor/pkg/oracle/product/10.2.0/rdbms//lib32/ -L/usr/vendor/pkg/oracle/product/10.2.0/lib32/ -L/usr/vendor/pkg/oracle/product/10.2.0/lib32/stubs/] Linking with /usr/vendor/pkg/oracle/product/10.2.0/rdbms/lib/defopt.o -lclntsh -ldl -lm -lpthread -lnsl -lirc -ldl -lm -lpthread [from $(DEF_OPT) $(OCISHAREDLIBS)] WARNING: If you have problems you may need to rebuild perl with threading enabled. Checking if your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. Note (probably harmless): No library found for -lirc LD_RUN_PATH=/usr/vendor/pkg/oracle/product/10.2.0/lib Using DBD::Oracle 1.22. Using DBD::Oracle 1.22. Using DBI 1.607 (for perl 5.01 on x86_64-linux) installed in /usr/local/lib/perl5/site_perl/5.10.0/x86_64-linux/auto/DBI/ Writing Makefile for DBD::Oracle *** If you have problems... read all the log printed above, and the README and README.help.txt files. (Of course, you have read README by now anyway, haven't you?) r...@devserver-165:~/.cpan/build/DBD-Oracle-1.22-4sDScg# And output of perl -V is: r...@devserver-165:~/.cpan/build/DBD-Oracle-1.22-4sDScg# perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.20-17-generic, archname=x86_64-linux uname='linux devserver-165.dev.s.net 2.6.20-17-generic #2 smp wed jul 9 22:24:42 utc 2008 x86_64 gnulinux ' config_args='' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing
Re: Prepare some SQL-statements before executing any.
Am Mo, 8.12.2008, 14:37, schrieb Deviloper: Hi there, I have a script which uses (lets say) 25 Queries in Loops. I want to prepare them all at the beginning of the script instead of doing something stupid like preparing them in the mainloop. My question is, how can I do this? Do I need 25 statementhandles? Or do I use prepare_cached() to cache them in this case? You use prepare_cached(). See http://search.cpan.org/~timb/DBI-1.607/DBI.pm#prepare_cached The caching only works if the prepared statement is the same (you can use bound parameters if you need to change conditions etc). You should definitely read the documentation because prepare_cached may affect old statement handles that are still active (thats the reason why preparing 25 statement handles before entering the loop wont work). Hendrik Thx, B.
Re: Protecting a mod perl 1.3 site from slow MySql processes
I searched a little bit and it seems that there can be problems with
signal handling in mod_perl under certain circumstances (though I never
had problems yet myself).
See
http://search.cpan.org/dist/mod_perl/docs/user/coding/coding.pod#Using_Signal_Handlers
Essentially
- signals wont work in a threaded mpm (shouldnt matter for you since you
are using apache 1.3),
- you should use the POSIX-signals (see link above for an example),
- signals can conflict with apache signals (apache 1.3 uses alarm for i/o
operations - but if you dont do a read/write inside your eval, that
shouldnt be a problem).
Also keep in mind that there can be other reasons why a code is working
when executed in a shell but isnt in mod_perl. Among others the DBD may
behave differently because of different ENV-vars.
Hendrik
Am Di, 2.12.2008, 22:30, schrieb April Papajohn (Blumenstiel):
On Tue, Dec 2, 2008 at 2:19 PM, Hendrik Schumacher [EMAIL PROTECTED]
wrote:
alarm() definitely works in mod_perl.
Then I wonder why my test code is successfully interrupting the
DBI-connect method from the command line, but not when running in
modperl 1.3 (the versions of perl are the same).
sub handler {
...
eval {
my $h = set_sig_handler('ALRM',sub {die DBD took longer than
$MYSQL_ALARM_LIMIT seconds to do its MySQL work\n});
alarm($MYSQL_ALARM_LIMIT);
my $dbh = DBI-connect($datasource,'','', {PrintError = 0});
if (!$dbh) {
warn $DBI::errstr;
} else {
my $data = rand();
my $sh2 = $dbh-prepare(select * from test where data = $data );
$sh2-execute;
my @result = $sh2-fetchrow_array;
warn Result fetched: @result\n;
}
};
alarm(0);
...
Re: Protecting a mod perl 1.3 site from slow MySql processes
alarm() definitely works in mod_perl.
For timeouts in DBI see:
http://search.cpan.org/~timb/DBI-1.607/DBI.pm#Signal_Handling_and_Canceling_Operations
Hendrik
Am Di, 2.12.2008, 16:22, schrieb April Papajohn (Blumenstiel):
Hello,
I am working on a site that has a modperl (mod_perl 1.3, perl 5.8)
handler doing some authentication work via DBI::MySql. It connects to
a MySQL server over the network.
Recently during some maintenance on the MySql server, the entire site
was hung up, because the MySQL server was up, but it wasn't
responding. It is important that the site continue to function, even
if MySql is down or slow. Sadly, I don't have the details on exactly
what they were doing with the MySql server that would cause this. I'm
working on limited information.
I was able to reproduce something like what may have happened simply
by pausing the MySql thread in my test environment. If I do that, the
web page does just hang.
The perl module wasn't dying, so wrapping everything in eval{} won't
solve the problem.
I tried setting alarm() around the DBI lines, using the Sys::SigAction
module, in order to get the script to timeout if MySql isn't
responsive. This works great if I run it as a plain perl script. But
it seems that alarm() doesn't work in mod perl.
So now I'm stuck.
I'm just looking for suggestions for possible solutions. Any way that
I can safe guard the site against a misbehaving MySql server.
Thanks,
April
Re: How to write a (My)SQL statement with REGEX / RLIKE containing a scalar variable?
I think the REGEX operator is correctly spelled REGEXP.
If you just want to find out, if the column contains a value, you should
consider using LIKE and the wildcard char %.
To avoid painful quoting the mysql reference manual suggest binding the
value like this:
$sth = $dbh-prepare (select name from toolbox where name LIKE
CONCAT('%', ? ,'%'));
$sth-execute ($name);
Hendrik
Am Do, 13.11.2008, 15:50, schrieb Deviloper:
-- Ursprüngliche Nachricht --
Von: Deviloper [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Datum: 13. November 2008 at 15:41
Betreff: How to write a (My)SQL statement with REGEX / RLIKE containing a
scalar variable?
I have a SQL-Statement with a Regular Expression and I want to use a
scalar in that expression: (Looking for something like $tool =~
m/\Q$x\E/ )
#Find tools with xx in the name:
$dbh-prepare (SELECT name FROM toolbox WHERE name REGEX '$x');
#or
$dbh-prepare (SELECT name FROM toolbox WHERE name RLIKE '$x');
$sth-execute();
my ($name_of_tool) = $sth-fetchrow_array;
$sth-finish();
(Don´t need to mention that this don´t work as expected, but I don´t
know how to escape it the right way. ^^)
Thanks,
B.
Re: DBI::Gofer howto?
I don't use DBI::Gofer, but according to cpan DBI::Gofer::Transport::mod_perl is in a different package (not DBI). Try installing GoferTransport-http. Hendrik Tim Bunce escribÃo: On Mon, Jul 28, 2008 at 07:11:04AM -0500, Brian Millett wrote: I've looked at the DBI::Gofer::Transport::mod_perl to setup a connection pooling server, but to be honest, I just can not grok it. How is it setup? The docs could certainly use some expansion to 'connect the dots'. So my question is has anyone set it up? Er, yes, me! :) How, or what are the configuration files. In the cpan docs, it has http://search.cpan.org/~timb/GoferTransport-http-1.015/lib/DBI/Gofer/Transport/mod_perl.pm add_configurations DBI::Gofer::Transport::mod_perl-add_configurations( \%hash_of_hashes ); Takes a reference to a hash containing gofer configuration names and their corresponding configuration details. What configurations?? The reference is vague. These: http://search.cpan.org/~timb/DBI/lib/DBI/Gofer/Execute.pm#CONFIGURATION For simple cases you don't need any configuration. Any pointers on how to setup a simple stateless proxy with DBI::Gofer::mod_perl would be nice. The docs say: ---snip--- The most simple configuration looks like: Location /gofer SetHandler perl-script PerlHandler DBI::Gofer::Transport::mod_perl /Location ---snip--- did you try that? Yes I did and got an error: [Sun Jul 27 18:21:46 2008] [error] [client 127.0.0.1] failed to resolve handler `DBI::Gofer::Transport::mod_perl': Can't locate DBI/Gofer/Transport/mod_perl.pm in @INC (@INC contains: /home/bpm/development/modperl/_Inline/lib /home/bpm/development/modperl/_Inline/lib /home/bpm/development/modperl /home/bpm/development/perl/DBI /usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 . /etc/httpd) at (eval 22) line 3.\n I'm using fedora 9 with perl-DBI-1.601-4.fc9. The DBI::Gofer::Transport::mod_perl does not seem to be installed. [bpm]$ rpm -ql perl-DBI-1.601-4.fc9.i386 | grep Gofer /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Policy /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Policy/Base.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Policy/classic.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Policy/pedantic.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Policy/rush.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Transport /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Transport/Base.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Transport/null.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Transport/pipeone.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBD/Gofer/Transport/stream.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Execute.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Request.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Response.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Serializer /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Serializer/Base.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Serializer/DataDumper.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Serializer/Storable.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Transport /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Transport/Base.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Transport/pipeone.pm /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/DBI/Gofer/Transport/stream.pm /usr/share/man/man3/DBD::Gofer.3pm.gz /usr/share/man/man3/DBD::Gofer::Policy::Base.3pm.gz /usr/share/man/man3/DBD::Gofer::Policy::classic.3pm.gz /usr/share/man/man3/DBD::Gofer::Policy::pedantic.3pm.gz /usr/share/man/man3/DBD::Gofer::Policy::rush.3pm.gz /usr/share/man/man3/DBD::Gofer::Transport::Base.3pm.gz /usr/share/man/man3/DBD::Gofer::Transport::null.3pm.gz /usr/share/man/man3/DBD::Gofer::Transport::pipeone.3pm.gz /usr/share/man/man3/DBD::Gofer::Transport::stream.3pm.gz /usr/share/man/man3/DBI::Gofer::Execute.3pm.gz /usr/share/man/man3/DBI::Gofer::Request.3pm.gz
Taint check on bind params
Hi. I use DBI and DBD::mysql (both up-to-date versions from cpan) in a mod_perl application. When constructing the SQL statements I 1) untaint the vars used to concat the actual statements 2) use (partly tainted) vars in bind_param() and execute(). In the eternal struggle for more security I tried to use Taint = 1 in my database connect now. Unfortunately using tainted vars in bind_param() and execute() results in Taint errors. Since I dont want to excessively filter the vars I use in my binds, the only solution would be to blindly untaint the bound vars. Is there a reason for the taint check of the bound params? Would there be any security risk in doing a $x =~ /^(.*?)$/; $x = $1; for the bound params? If not, why does DBI taint check them? How should I proceed? I appreciate any help. Thanks in advance. Hendrik
Re: Taint check on bind params
Thanks for the reply (and the DBI, its great). Just one additional question: Can unchecked data somehow harm the database? I guess the definite answer depends on the database server but usually the database should not care about the inserted data (apart from size), right? I know there are alway security risks to consider, I just dont want to overlook something important. I will probably do an unchecked untainting of the bind params and treat the data from the database carefully (with the assistance of TaintOut). Hendrik Am Mo, 3.03.2008, 21:37, schrieb Tim Bunce: On Mon, Mar 03, 2008 at 03:04:33PM +0100, Hendrik Schumacher wrote: Hi. I use DBI and DBD::mysql (both up-to-date versions from cpan) in a mod_perl application. When constructing the SQL statements I 1) untaint the vars used to concat the actual statements 2) use (partly tainted) vars in bind_param() and execute(). In the eternal struggle for more security I tried to use Taint = 1 in my database connect now. Unfortunately using tainted vars in bind_param() and execute() results in Taint errors. Since I dont want to excessively filter the vars I use in my binds, the only solution would be to blindly untaint the bound vars. Is there a reason for the taint check of the bound params? Yes. Would there be any security risk in doing a $x =~ /^(.*?)$/; $x = $1; for the bound params? That depends on your application. If not, why does DBI taint check them? How should I proceed? SQL Injection attacks are just one kind of security problem. Tainting prevents unchecked data getting into the database tables, as well as preventing it 'corrupting' the SQL. (Arguably there's little point in taint checking placeholders that are only used in a where clause, for example, but the DBI has no way of knowing how placeholders are being used.) Tim.
