Re: db2 - persistent connection
On Monday 04 September 2006 22:28, Jack Faley ( The Tao of Jack ) wrote: Thank you for your reply. If their was any way to mitigate the small exits I would do it but I'm modifying an app that was never meant to be extensible. So, you are correct, Im moving the load to a daemon in the middle with a persistant connection rather than directly talking to DB2 :-) . I havent benchmarked it. Im no dba but I have a feeling this will actually be slower overall. I don't see it being a DBA question - it's a machine resource question. If you have n apps connecting to DB2, you need n sockets. But if you have n apps connecting to a proxy which itself connects to DB2, you have n+1 sockets. If that proxy is on another machine, then you may save some resource. But if the proxy is on the same machine as the server, there's no way this will be as fast as direct connection, though it may not be noticeably slower, either, depending on the hardware. e.g., a single CPU on a fully loaded system will be much slower, but an 8-way system that is only 90% loaded may not be noticed. I am holding hope DBD:Proxy connect_cached might do the trick but the docs seem to indicate its not fully completed. No harm in trying though. Even if it doesnt, I'll check the dba's quality to see if they can tell if there are still all those connections after a middleware to pool them that actually doesn't do anything. Each client will need to make a direct, individual, non-cacheable connection to the proxy. The proxy can make a cached connection to the server (as long as the previous connection isn't timed out, this will be pretty much a no-op). Note also that in this scenario, all exits must use the same authentication - if you're trying to get some stuff done as sysadm, and other stuff done as someone unprivileged, you'll need a different proxy for each user. How would Stored Procedures help? Just for the performance after connected? Stored procedures start as pre-connected from the server. Not that DB2 allows Perl-based stored procedures, so you'd also have to rewrite them. But I'm not even sure that the logic you're doing will fit as a stored procedure - I brought it up more as a poke to make you think about whether this stuff is better as a stored procedure or not.
Re: db2 - persistent connection
On Saturday 02 September 2006 00:21, Jack Faley ( The Tao of Jack ) wrote: I have several ( 100 - 200 ) small exits c oming from an app that update db2 tables. This works fine but the dba's don't like that many open connection overheads. This isn't cgi/apache. These are all seperate terminating processes. From what I gather there is no way to pass the dbh between processes? No. Is some sort of middle daemon ( I guess non perl ) that keeps one persistent connection to db2 and then have perl feed the daemon the only option? That would be called ... DB2 ;-) I would think others have run into this wall before? Option 1: stop during this in a bunch of small exits - put them in a single exit. Probably not a real option. Option 2: can you put this in stored procedures instead? Option 3: DBD::Proxy may help here. Or at least the concept - set up a POE-based pseudo-server which receives messages from apps, and funnels them via a single connection to your server, then passes the results back. That sounds like not only a lot of work to write, but also a lot of work for the computer. Oh, and all those connections just moved from going directly to the server to directly to the proxy/concentrator - I'm not really seeing a savings there. To be honest, I suspect that any option (other than a complete re-architecture of how you approach the business problem you're dealing with in these exits) will actually be a larger load on the system than what you're currently working with. If option 1 works (which I doubt from what little info was in your original question), I think it's probably the only solution that would satisfy your DBAs. But then again, I'm not seeing their problem, nor really what is causing it, so I'm just taking a wild guess ;-)
Re: compilation requirements for DBD-DB2
On October 12, 2004 1:27 pm, Edward Peschko wrote: hey all, I'm missing a piece, I guess, in the install of DB2.. I have the libraries, etc. installed in /opt/IBM/db2/V8.1. Did you install the application development tools with DB2? If you have the Application Development Client installed, you have it. Or, if you have any licensed product, you could install it (it's optional). If you have the Runtime Client or the Administration Client products, you will need to get the Application Development Client off the IBM website and install it to get the headers and libraries required for compiling C programs. I'm getting: Constants.xs:16:20: sqlcli.h: No such file or directory Constants.xs:18:21: sqlcli1.h: No such file or directory Constants.xs:19:20: sqlext.h: No such file or directory so... what do I need to download and from where?
Re: Perl / DB2 administrative API
On August 6, 2004 6:54 am, [EMAIL PROTECTED] wrote: [ Not really DBI related, but Tim suggested I post here ] We're starting to write our own administration functions for DB2, and are currently developing a perl module that provides access (through XS code) to the DB2 administrative API. This allows us to perform tasks like getting database snapshots, decoding binary snapshot and event data, getting/setting configuration options, etc - without going through the db2 command line processor. We've succesfully used this to write DB2 monitoring tools. In a similar vein, generating DB2 catalog files (which are binary and differ per platform / DB2 release) is a pain using the DB2 tools; we've reverse-engineerd the files and written (pure perl) modules so we can generate them directly from perl. We're considering open-sourcing these modules, but before starting the internal argument (lawyers get involved) I'd like to find out whether anyone in the perl / DBI community would be interested in using such an API. If you are, please let me know and prepared to be patient while we sort things out internally. I've been after the author of DBD::DB2 to provide much of this as private functions in the driver itself ... I wonder if you could bypass some (probably not all) of the lawyering by donating it to the DBD::DB2 author in the form of patches. Since DBD::DB2 is written by IBM itself, if IBM released it, that would take care of some of the concerns, wouldn't it?
Re: Help with DB2 DBI Connection
On July 29, 2004 9:53 am, Jay harris wrote: I am onsite at a client, and they use AIX/DB2-UDB V8. They have an automated scheduling package that starts jobs using su super user, and then passes the account like a nohup would do. My problem is that the dbi connect seems to require a password, but I do not have access to the password. They (the company) will not give the users access to run production jobs that connect to the database. Is there a way to connect without a password. My Unix shell scripts can connect because when the DB2 command is issued it defaults to the logged on user. Any help would be greatly appreciated. What user are you su'ing to? That's the user that needs to be GRANTed access to the database. (Hopefully, it's not a user with uid=0.)
Re: db2 with apache2 cgi
On June 1, 2004 1:47 pm, Alec Brecher wrote:
kind of an apache2 crossover problem: when perl cgi scripts using dbi:db2
are called I get the total enviroment failure error.
I can run scripts using dbi:db2 from the shell without a problem. Can
anyone offer some hints?
Set $ENV{DB2INSTANCE} in a BEGIN{} block, e.g.:
BEGIN { $ENV{DB2INSTANCE} = 'db2inst1' }
You may not need to do it in a BEGIN block, perhaps just doing it prior
to calling DBI-connect, but I've always just done it in BEGIN.
Re: Antwort: Re: Access into MVS DB2 using DBI or ???
On April 5, 2004 5:00 pm, Wagner, David --- Senior Programmer Analyst --- WGO
wrote:
[EMAIL PROTECTED] wrote:
Hi,
as I already mentioned this morning, you don't need anything special
in
perl to access a DB2 on a mainframe nor on any other operating system.
All You need is dbi and depending on how you like it e.g. dbd::db2 or
dbd:odbc !
On the machine where you run your perl script you need the
db2-connection
properly configured to your target-db2-system.
Everything I have received says it should be easy, but I can not get
anyhting but an error. I have tried all types of variations and no matter
what I do, it says either argument error or invalid table name.
I presume you can connect from the db2 commandline processor (db2.exe)?
If so, what is the exact connect command you give it? It should be
something like:
CONNECT TO db_name USER username USING password
(feel free to not give the password ;-)
Assuming this, then you would need to connect via perl using:
my $dbh = DBI-connect('dbi:DB2:db_name', 'username', 'password');
My guess would be that you haven't cataloged the MVS db locally. Note
that to do this, you either need to have DB2 Connect Personal Edition,
DB2 Connect Enterprise Edition, or DB2 UDB Enterprise Server Edition
installed locally, or you must have a gateway set up with DB2 Connect
Enterprise Edition or DB2 UDB Enterprise Server Edition installed. For
help on this aspect, I would recommend comp.databases.ibm-db2 as it's
not really a DBI issue.
Now I can get the datasources or the driver info.
So I have the following for:
Driver Info:
DB2
ODBC
Data sources:
dbi:DB2:AFDSNP
dbi:DB2:AFDSNT
My file name is 'PS_FXF_BU_XLAT'.
Given the above, what would be the right commands to connect:
I have done nothing with DB2 on my XP machine. IN the statement below,
Here you have to add the cataloged db2-alias e.g. D2HOST for your
mainframe
which does not say anything to me.
Just another way of saying the above ;-)
I admit being a newbie to the DBI side, but using Perl for a number years.
I have looked at the doc and tried a number of things, but I must be
missing the most basic of things.
Would there be another list which could help? I am at my wits end ( which
may not even be much of an end), but I am.
Thanks for any insight or EXAMPLES of working Windows to MVS scripts. Not
trying to update, but just want to select and display.
Once you have the CLP working, then we can work on the DBI stuff, but I
suspect that the DBI stuff will be trivial once the CLP works. It
always is for me!
make test problems
As I was testing another module that used DBI, I found some interesting behaviour while trying to trace/debug my DBI interactions. Rather than posting a bunch of code, I managed to find that I could reproduce this with the DBI 1.42 distribution directly. The problem is that turning on trace seems to throw the entire DBI stack (including the caller) out of whack. Here's a snippet from doing that with just the DBI tests. The actual problem I got was similar to the printf problem at the bottom. Note that if I leave off trace, the entire test suite runs absolutely perfectly ... as does my module (now that I got a fix from the DBD owner to fix the original problem). # DBI_TRACE=9=dbitrace.log make test PERL_DL_NONLAZY=1 /home/share/perl5/bin/perl5.8.3 -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/01basics.ok t/02dbidrv.ok t/03handle.ok 25/52SV = PVMG(0x8263448) at 0x831ce80 REFCNT = 1 FLAGS = (OBJECT) IV = 0 NV = 0 PV = 0x831d5a0 CUR = 0 LEN = 113 STASH = 0x8264720 DBD::ExampleP::db_mem t/03handle.ok t/04mods...ok t/05thrclone...skipped all skipped: this linux perl 5.008003 not configured to support iThreads t/06attrs..# Failed test (t/06attrs.t at line 46) # got: '0' # expected: '9' # Failed test (t/06attrs.t at line 99) # got: '0' # expected: '9' # Failed test (t/06attrs.t at line 153) # got: '0' # expected: '9' t/06attrs..ok 107/143# Looks like you failed 3 tests of 143. t/06attrs..dubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 22, 61, 98 Failed 3/143 tests, 97.90% okay t/07kids...ok t/08keeperrok t/09trace..# Failed test (t/09trace.t at line 26) # got: '0' # expected: '9' # Failed test (t/09trace.t at line 54) # got: '265' # expected: '256' # Failed test (t/09trace.t at line 54) # got: '16777225' # expected: '16777216' # Failed test (t/09trace.t at line 54) # got: '33554441' # expected: '33554432' # Failed test (t/09trace.t at line 54) # got: '67108873' # expected: '67108864' # Failed test (t/09trace.t at line 54) # got: '134217737' # expected: '134217728' # Failed test (t/09trace.t at line 54) # got: '268435465' # expected: '268435456' t/09trace..NOK 49- trace= 9 at t/09trace.t line 98 disconnect DISPATCH (DBI::db=HASH(0x8145874) rc1/1 @1 g0 imac01 pid#9044) at t/09trace.t line 21 via t/09trace.t line 0 - disconnect for DBD::ExampleP::db (DBI::db=HASH(0x8145874)~0x82d86cc) STORE DISPATCH (DBI::db=HASH(0x82d86cc) rc1/1 @3 g0 ima41c pid#9044) at /root/.cpan/build/DBI-1.42/blib/lib/DBD/ExampleP.pm line 199 via t/09trace.t line 21 1 - STORE for DBD::ExampleP::db (DBI::db=HASH(0x82d86cc)~INNER 'Active' 0) STORE DBI::db=HASH(0x82d86cc) 'Active' = 0 1 - STORE= 1 at /root/.cpan/build/DBI-1.42/blib/lib/DBD/ExampleP.pm line 199 via t/09trace.t line 21 - disconnect= 1 at t/09trace.t line 21 via t/09trace.t line 0 -- DBI::END disconnect_all DISPATCH (DBI::dr=HASH(0x8257eb4) rc1/4 @1 g0 ima801 pid#9044) at /root/.cpan/build/DBI-1.42/blib/lib/DBI.pm line 657 via t/09trace.t line 0 - disconnect_all for DBD::ExampleP::dr (DBI::dr=HASH(0x8257eb4)~0x8145838) - disconnect_all= (not implemented) at /root/.cpan/build/DBI-1.42/blib/lib/DBI.pm line 657 via t/09trace.t line 0 # Looks like you failed 7 tests of 65. DESTROY DISPATCH (DBI::db=HASH(0x8145874) rc1/1 @1 g0 ima4 pid#9044) DESTROY ignored for outer handle DBI::db=HASH(0x8145874) (inner DBI::db=HASH(0x82d86cc) has ref cnt 1) DESTROY DISPATCH (DBI::db=HASH(0x82d86cc) rc1/1 @1 g0 ima4 pid#9044) - DESTROY for DBD::ExampleP::db (DBI::db=HASH(0x82d86cc)~INNER) FETCH DISPATCH (DBI::db=HASH(0x82d86cc) rc1/2 @2 g0 ima404 pid#9044) at /root/.cpan/build/DBI-1.42/blib/lib/DBD/ExampleP.pm line 236 via t/09trace.t line 0 - FETCH for DBD::ExampleP::db (DBI::db=HASH(0x82d86cc)~INNER 'Active') .. FETCH DBI::db=HASH(0x82d86cc) 'Active' = '' - FETCH= '' at /root/.cpan/build/DBI-1.42/blib/lib/DBD/ExampleP.pm line 236 via t/09trace.t line 0 - DESTROY= undef DESTROY (dbih_clearcom) (dbh 0x8145874, com 0x8219c38, imp DBD::ExampleP::db): FLAGS 0x100291: COMSET Warn RaiseError PrintWarn AutoCommit PARENT DBI::dr=HASH(0x8145838) KIDS 0 (0 Active) IMP_DATA undef dbih_clearcom 0x8145874 (com 0x8219c38, type 2) done. !DESTROY DISPATCH (DBI::dr=HASH(0x8145838) rc1/1 @1 g0 ima4 pid#9044) during global destruction ! - DESTROY for DBD::ExampleP::dr (DBI::dr=HASH(0x8145838)~INNER) ! - DESTROY= undef during global destruction DESTROY (dbih_clearcom) (drh 0x8257eb4, com 0x82c7428, imp global destruction):
Re: make DBI-1.35 Fails on HP-UX 11i and Perl 5.8.0
On April 4, 2003 01:41 pm, [EMAIL PROTECTED] wrote:
That is why the DBI build fails. Work with your systems folks to make sure
you have a good GCC on this box. How could you have possibly built perl
with gcc on this box?
Read the README.hpux that comes with DBD-Oralce.
Lincoln
215-444-7973 (office)
267-716-1370 (cellular)
-Original Message-
From: mkb [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 2:32 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: make DBI-1.35 Fails on HP-UX 11i and Perl 5.8.0
#include socket
If you're in C (rather than C++), this pretty much definitely has to be
socket.h, not just socket.
Even C++ probably needs this to be socket.h.
int main() { exit(0); };
gcc -o t.o -c t.c
gives
t.c:1:18: socket: No such file or directory. Not
being a C programmer, I'm not sure how I'd get the
compiler to include this header. Any ideas?
The socket.h files are located here:
/usr/conf/sys/socket.h
/usr/include/sys/socket.h
And BTW, gcc -v gives the following:
Reading specs from
/usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.2/specs
Configured with: ./configure : (reconfigured)
./configure : (reconfigured) ./configure :
(reconfigured) ./configure : (reconfigured)
./configure : (reconfigured) ./configure :
(reconfigured) ./configure : (reconfigured)
./configure : (reconfigured) ./configure :
(reconfigured) ./configure : (reconfigured)
./configure
Thread model: posix
gcc version 3.2
thanks
mohammed
--- [EMAIL PROTECTED] wrote:
This looks like your GCC can not parse
/usr/include/socket.h
Can you test that?
cat t.c EOF
#include socket
int main() { exit(0); }
EOF
gcc -o t.o -c t.c
Lincoln
215-444-7973 (office)
267-716-1370 (cellular)
-Original Message-
From: mkb [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 12:15 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: make DBI-1.35 Fails on HP-UX 11i and Perl
5.8.0
I'm trying to install DBI-1.35 on HP-UX 11.11 and
Perl
5.8.0. During the make stage I get the following
errors:
Steps I took...
uname -a
B.11.11 U 9000/800 691359336 unlimited-user license
I did a make realclean
then perl Makefile.PL
snip
Checking if your kit is complete...
Looks good
Writing Makefile for DBI
Then make (here's the output):
cp Changes blib/lib/DBI/Changes.pm
cp dbd_xsh.h blib/arch/auto/DBI/dbd_xsh.h
cp lib/DBI/FAQ.pm blib/lib/DBI/FAQ.pm
cp Driver_xst.h blib/arch/auto/DBI/Driver_xst.h
cp lib/DBD/Proxy.pm blib/lib/DBD/Proxy.pm
cp DBI.pm blib/lib/DBI.pm
cp lib/DBI/Const/GetInfoReturn.pm
blib/lib/DBI/Const/GetInfoReturn.pm
cp DBIXS.h blib/arch/auto/DBI/DBIXS.h
cp lib/DBI/Const/GetInfo/ANSI.pm
blib/lib/DBI/Const/GetInfo/ANSI.pm
cp lib/DBD/Sponge.pm blib/lib/DBD/Sponge.pm
cp lib/DBI/Const/GetInfoType.pm
blib/lib/DBI/Const/GetInfoType.pm
cp lib/DBI/W32ODBC.pm blib/lib/DBI/W32ODBC.pm
cp lib/DBI/DBD/Metadata.pm
blib/lib/DBI/DBD/Metadata.pm
cp lib/Bundle/DBI.pm blib/lib/Bundle/DBI.pm
cp lib/DBI/Const/GetInfo/ODBC.pm
blib/lib/DBI/Const/GetInfo/ODBC.pm
cp lib/DBI/ProfileDumper/Apache.pm
blib/lib/DBI/ProfileDumper/Apache.pm
cp lib/DBI/Profile.pm blib/lib/DBI/Profile.pm
cp Driver.xst blib/arch/auto/DBI/Driver.xst
cp lib/DBI/ProfileDumper.pm
blib/lib/DBI/ProfileDumper.pm
cp lib/DBI/ProxyServer.pm
blib/lib/DBI/ProxyServer.pm
cp dbipport.h blib/arch/auto/DBI/dbipport.h
cp lib/DBD/NullP.pm blib/lib/DBD/NullP.pm
cp lib/DBI/DBD.pm blib/lib/DBI/DBD.pm
cp lib/Win32/DBIODBC.pm blib/lib/Win32/DBIODBC.pm
cp dbi_sql.h blib/arch/auto/DBI/dbi_sql.h
cp lib/DBD/ExampleP.pm blib/lib/DBD/ExampleP.pm
cp lib/DBI/PurePerl.pm blib/lib/DBI/PurePerl.pm
cp lib/DBI/ProfileData.pm
blib/lib/DBI/ProfileData.pm
/usr/local/bin/perl -p -e
s/~DRIVER~/Perl/g
blib/arch/auto/DBI/Driver.xst Perl.xsi
/usr/local/bin/perl
/usr/local/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap
/usr/local/lib/perl5/5.8.0/ExtUtils/typemap Perl.xs
Perl.xsc mv Perl.xsc Perl.c
gcc -c-D_HPUX_SOURCE
-fno-strict-aliasing
-D_LARGEFILE_SOURCE -DVERSION=\1.35\
-DXS_VERSION=\1.35\ -fPIC
-I/usr/local/lib/perl5/5.8.0/PA-RISC2.0/CORE
-Wall
-Wno-comment -DDBI_NO_THREADS Perl.c
In file included from
/usr/local/lib/perl5/5.8.0/PA-RISC2.0/CORE/perl.h:681,
from DBIXS.h:19,
from Perl.xs:1:
/usr/include/sys/socket.h:484: parse error before
sendfile
/usr/include/sys/socket.h:485: parse error before
bsize_t
/usr/include/sys/socket.h:486: parse error before
sendpath
/usr/include/sys/socket.h:487: parse error before
bsize_t
*** Error exit code 1
Stop.
Output of perl -V is:
Summary of my perl5 (revision 5.0 version 8
subversion
0) configuration:
Platform:
osname=hpux, osvers=11.00, archname=PA-RISC2.0
uname='hp-ux quioch
quote vs placeholders (was Re: Huge performance difference between command line and DBI interfaces Solved)
On March 31, 2003 10:41 am, Ronald J Kimball wrote:
On Mon, Mar 31, 2003 at 11:42:37AM -0600, Michael Muratet wrote:
I have discovered that it is the placement of single quotes around the
key value in the query:
my $rth = $dbh-prepare(SELECT * FROM demographics_1 WHERE
KEY1=$key);
that makes the difference. The above takes 90 secs.
The below takes milliseconds (as it does from the command line):
my $rth = $dbh-prepare(SELECT * FROM demographics_1 WHERE
KEY1='$key');
Without the single quotes, the command line interface will tell you that
you have a bogus column name. I guess the DBI interface is able to
figure it out, but it takes awhile.
What is the value of $key?
Anyway, you should probably be using placeholders.
Excuse my ignorance, but I'm trying to figure out why people would not be
using placeholders (excepting legacy code, perhaps)? It seems to solve
nearly every other problem I've seen while lurking on this list and have the
fewest gotchas.
sub get_keys
{
my $dbh = shift;
my @keys = @_;
my $sth = $dbh-prepare('SELECT * FROM demographics_1 WHERE KEY1 IN (' .
join(,, map { '?' } @keys) . ')');
$sth-execute(@keys);
$sth-fetchall_arrayref();
}
It doesn't seem that difficult to me - no more so than handling an arbitrary
number of possible matches without placeholders.
sub get_keys_no_placeholders
{
my $dbh = shift;
my @keys = @_;
$dbh-selectall_arrayref('SELECT * FROM demographics_1 WHERE KEY1 IN (' .
join(,, map { $dbh-quote($_) } @keys }) . ')');
}
The single possibility case seems even better for placeholders since there's
no quoting.
Perhaps someone can enlighten me?
Thanks,
Re: DBD::DB2 Do I need to compile on each box or can I copy the installed version to another box? (AIX)
On February 5, 2003 10:29 am, [EMAIL PROTECTED] wrote: Hello, My environment is as follows: AIX 4.3.3.0 running perl 5.005_03 Installed DBI 1.32 Installed DB2 vsn 7.2 I'm requiring install of the DBD::DB2 driver onto a number of AIX RS6000 machines. The install originally failed compilation because I hadn't installed the DB2 Application Development Client. I've been told by our DBA that the Application Development Client could be installed onto one of our test boxes in order to install DBD::DB2 to that box, however it is not allowed on any of the Live boxes. My question That's strange. In version 7, you need the Application Development Client installed on your live boxes if you want to compile SQL stored procedures. Further, there's no licensing for the App Dev Client, and thus won't cost HSBC any more money. therefore is would it be feasible to install DBI and DBD::DB2 on one RS6000 and then copy the compiled code to the 'Live' boxes (all running the same version of Perl), without the need to install from scratch? (and by implication, without the need to install then Application Development Client on the Live boxes or compile any code on these boxes). The DBD::DB2 driver should not need the App Dev Client to *run*, only to compile. Thus if your perl is compiled with the same compiler on all AIX boxes (which is very likely), and you use the same compiler to compile your driver, it should work. Hint: (not that I've tried this before) Try compiling it/testing it on one box, and then tar up the entire DBD-DB2-0.76 (or whatever version you're using) directory after the make/make test/make install is complete. Take that tarball to the next machine, and try make test/make install. Unless others on this list think this is a Bad Idea in general, I'm guessing it should work fine. The advantage is that perl is still doing the installation everywhere. Any help would be greatly appreciated, otherwise I doubt we will be able to use DBI at all and will have to code our own database interface. Yes, and that would definitely suck.
Re: use DBD::Oracle qw(:ora_types); - from cron
On November 6, 2002 02:42 pm, Fox, Michael wrote:
Thanks Darin,
Actually, because I 'use strict', option 2 failed with compile errors
like: Bareword ORA_RSET not allowed while strict subs in use at
That's easy:
{
no strict 'subs';
eval 'use DBD::Oracle qw(:ora_types)';
die $@ if $@;
}
or:
eval 'no use strict q{subs}; use DBD::Oracle qw(:ora_types)';
die $@ if $@;
Either one of these should work.
Note: I actually don't have/use Oracle, so I can't actually test this
stuff directly. ;-)
So I will perservere with re-organising my program so option 1 will work
Michael Fox
-Original Message-
From: Darin McBride [mailto:darin;naboo.to.org]
Sent: Wednesday, November 06, 2002 11:33 AM
To: [EMAIL PROTECTED]
Subject: Re: use DBD::Oracle qw(:ora_types); - from cron
On November 5, 2002 04:41 pm, you wrote:
When I need to have a use DBD::Oracle qw(:ora_types); in my program,
and I am running from cron, I get a message like:
Can't load 'long path/auto/DBD/Oracle/Oracle.so' for module
DBD::Oracle:'
at the use DBD::Oracle line.
Other programs that just have a 'use DBI' are fine. The normal program
structure I have so that programs work from cron is like:
use DBI;
setup Oracle variables, including LD_LIBRARY_PATH
$dbh=DBI-connect($dsn, $username, $password, { ora_module_name = $me })
etc
but as soon as I add;
use DBD::Oracle qw(:ora_types);
I get the error, because the symbol import is done at compile time,
before my program has had a chance to set up the environment properly.
Any ideas how to get around this problem? So far I am explicitly setting
LD_LIBRARY_PATH in the crontab entry, but I was trying to have it all
happen inside the program.
Two basic ideas:
BEGIN { setup Oracle variables, etc. }
use DBD::Oracle qw(:ora_types);
or:
eval 'use DBD::Oracle qw(:ora_types)';
die $@ if $@;
The first one gets your environment set up before the use, since BEGIN
is executed during compilation, while the second option will delay the
compilation of the use DBD::Oracle until the eval is reached.
Personally, I would suggest the first option where possible.
Australia Post is committed to providing our customers with excellent
service. If we can assist you in any way please either telephone 13 13 18
or visit our website www.auspost.com.au.
CAUTION
This e-mail and any files transmitted with it are privileged and
confidential information intended for the use of the addressee. The
Which addressee? :-)
confidentiality and/or privilege in this e-mail is not waived, lost or
destroyed if it has been transmitted to you in error. If you have
received this e-mail in error you must (a) not disseminate, copy or take
any action in reliance on it; (b) please notify Australia Post
immediately by return e-mail to the sender; and (c) please delete the
original e-mail.
Australia Post is committed to providing our customers with excellent
service. If we can assist you in any way please either telephone 13 13 18
or visit our website www.auspost.com.au.
CAUTION
This e-mail and any files transmitted with it are privileged and
confidential information intended for the use of the addressee. The
confidentiality and/or privilege in this e-mail is not waived, lost or
destroyed if it has been transmitted to you in error. If you have received
this e-mail in error you must (a) not disseminate, copy or take any action
in reliance on it; (b) please notify Australia Post immediately by return
e-mail to the sender; and (c) please delete the original e-mail.
Re: use DBD::Oracle qw(:ora_types); - from cron
On November 5, 2002 04:41 pm, you wrote:
When I need to have a use DBD::Oracle qw(:ora_types); in my program, and
I am running from cron, I get a message like:
Can't load 'long path/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle:'
at the use DBD::Oracle line.
Other programs that just have a 'use DBI' are fine. The normal program
structure I have so that programs work from cron is like:
use DBI;
setup Oracle variables, including LD_LIBRARY_PATH
$dbh=DBI-connect($dsn, $username, $password, { ora_module_name = $me })
etc
but as soon as I add;
use DBD::Oracle qw(:ora_types);
I get the error, because the symbol import is done at compile time, before
my program has had a chance to set up the environment properly.
Any ideas how to get around this problem? So far I am explicitly setting
LD_LIBRARY_PATH in the crontab entry, but I was trying to have it all
happen inside the program.
Two basic ideas:
BEGIN { setup Oracle variables, etc. }
use DBD::Oracle qw(:ora_types);
or:
eval 'use DBD::Oracle qw(:ora_types)';
die $ if $;
The first one gets your environment set up before the use, since BEGIN
is executed during compilation, while the second option will delay the
compilation of the use DBD::Oracle until the eval is reached.
Personally, I would suggest the first option where possible.
Australia Post is committed to providing our customers with excellent
service. If we can assist you in any way please either telephone 13 13 18
or visit our website www.auspost.com.au.
CAUTION
This e-mail and any files transmitted with it are privileged and
confidential information intended for the use of the addressee. The
Which addressee? :-)
confidentiality and/or privilege in this e-mail is not waived, lost or
destroyed if it has been transmitted to you in error. If you have received
this e-mail in error you must (a) not disseminate, copy or take any action
in reliance on it; (b) please notify Australia Post immediately by return
e-mail to the sender; and (c) please delete the original e-mail.
Re: Problem with set DB2_HOME environment variable during install DBD:DB2
On October 24, 2002 07:20 pm, Limei Zhang wrote: Hi, there, I am using DB2 Runtime client (V7.2) on linux redhat 7.3. I am try to install DBD:DB2 (0.76)that I can run perl program to remote access database in the DB2 server. You need to use the Application Development Client to compile the DBD::DB2 driver. DBD::DB2 requires some of the header files and libraries that only come with the App Dev Client in order to compile. I have successfully install DBI. When I do Perl Makefile.PL It failed, and the error message is DB2_HOME environment variable must be set to installed location of DB2 Then I type set DB2_HOME = /usr/IBMdb2/V7.1/ export DB2_HOME What shell are you using? If you're using bash, you should do: export DB2_HOME=/usr/IBMdb2/V7.1 If you're using csh, you should do: setenv DB2_HOME /usr/IBMdb2/V7.1 I don't know of any shell that uses the syntax you gave above. This does not help, same error came up. Could anyone give me some hint? Thanks in advance. zlm
