On 28.10.2009 20:38, jeff wrote:
Hi all,
Hope someone can help.
I need to talk to both an oracle 8 and oracle 10 server in the same
script using their respective "external connections" capabilities (i.e.,
no user name or password -- system authentication on 8 & wallet on
10 ).
Install the Oracle 10 Client libraries and let them handle the
connection to both Oracle 8 server and Oracle 10 server. A difference
of "only" two major version numbers should be no problem for them. See
below.
Hacked up a version of DBD to get everything renamed from 'Oracle' to
'Oracle8' and built against Oracle 8 libs. The other is built against
Oracle 10 libs. So I've 2 different builds in the same perl build:
Much, much unneeded pain that way.
I'm reading from a single tns_names.ora.
( SERV2 is Oracle 10 & SERV1 is Oracle 8 )
So, why don't you use the same client libs?
ORACLE_HOME is the same each time.
That obviously can not work. If you have two sets of client libraries,
you need two different ORACLE_HOMEs.
LD_LIBRARY_PATH includes 2 entries - 1 for Oracle 10 lib directory
and 1 for Oracle 8.
So one of the DBDs will succed loading the libs, and the other will fail.
So the environment is the same every time.
Sure, but it is broken.
I can:
--------------------------------------------
use DBD::Oracle8;
my $db3=DBI->connect("dbi:Oracle8:SERV1",'','');
--------------------------------------------
Wrong. You NEVER load the DBD manually, DBI does that for you. And your
code lacks the standard error check documented in the DBI documentation.
Or I can:
--------------------------------------------
use DBD::Oracle;
my $db3=DBI->connect("dbi:Oracle:SERV2",'','');
--------------------------------------------
Wrong, as above.
but:
--------------------------------------------
use DBD::Oracle8;
use DBD::Oracle;
my $db3=DBI->connect("dbi:Oracle8:SERV1",'','');
my $db3=DBI->connect("dbi:Oracle:SERV2",'','');
--------------------------------------------
Will make both connections successfully, but exits
with a segmentation fault
Of course it segfaults, because one of the DBDs was compiled against
Oracle 8 client libs, and the other against Oracle 10 client libs, and
both attempt to load the same external libraries, because your
ORACLE_HOME is always wrong for one of the DBDs.
Or if I reverse the connections:
--------------------------------------------
use DBD::Oracle8;
use DBD::Oracle;
my $db3=DBI->connect("dbi:Oracle:SERV2",'','');
my $db3=DBI->connect("dbi:Oracle8:SERV1",'','');
--------------------------------------------
first connection succeeds and second fails.
Sure. Same reason.
Also, these obviously fail because of wrong Oracle version:
--------------------------------------------
use DBD::Oracle;
my $db3=DBI->connect("dbi:Oracle:SERV1",'','');
--------------------------------------------
--------------------------------------------
use DBD::Oracle8;
my $db3=DBI->connect("dbi:Oracle8:SERV2",'','');
--------------------------------------------
Any ideas as to why? Thanks.
Yes. Wrong way.
Get rid of all the files you created by torturing DBD::Oracle into your
DBD::Oracle8. Uninstall the Oracle 8 client. And to be sure, remove
DBD::Oracle and the Oracle 10 client, re-install the Oracle 10 client,
re-install an unmodified DBD::Oracle and compile it against the Oracle
10 client.
This way, you will end with a single DBD::Oracle compiled against Oracle
10 client, and all those binary code provided by Oracle, hidden in
several libraries, will take care of connecting to the Oracle 8 server.
Your Perl code will simply look like this:
#!/usr/bin/perl
use warnings;
use strict;
use DBI;
# no "use DBD::Oracle"!
my $ora8=DBI->connect('dbi:Oracle:SERV1','','') or die "Can't connect to
SERV1: $DBI::errstr";
my $ora10=DBI->connect('dbi:Oracle:SERV2','','') or die "Can't connect
to SERV2: $DBI::errstr";
See also
<http://search.cpan.org/~pythian/DBD-Oracle-1.23/Oracle.pm#CONNECTING_TO_ORACLE>
and
<http://search.cpan.org/~pythian/DBD-Oracle-1.23/Oracle.pm#CONNECTING_TO_ORACLE_II>
for a long discussions of all the strange ways you can use to connect to
Oracle.
Alexander
--
Alexander Foken
mailto:alexan...@foken.de http://www.foken.de/alexander/
