Probably a silly question, but why do you need two versions of
DBD::Oracle?  Can't you build DBD::Oracle against an Oracle client
that is able to connect to both versions?  I know the 9i client we
currently use will connect to both 9i and 11g DB instances.  I'm
pretty sure a couple of years ago we had a version that would connect
to Oracle 7 and 9i.

May be a bit less hassle.

Steve

On Thu, Oct 29, 2009 at 6:41 AM, Martin J. Evans
<martin.ev...@easysoft.com> wrote:
> 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 ).
>>
>> 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:
>>
>> ./lib/site_perl/5.8.9/i686-linux/DBD/Oracle.pm
>> ./lib/site_perl/5.8.9/i686-linux/DBD/Oracle8.pm
>> ./lib/site_perl/5.8.9/i686-linux/auto/DBD/Oracle/Oracle.h
>> ./lib/site_perl/5.8.9/i686-linux/auto/DBD/Oracle/Oracle.so
>> ./lib/site_perl/5.8.9/i686-linux/auto/DBD/Oracle/Oracle.bs
>> ./lib/site_perl/5.8.9/i686-linux/auto/DBD/Oracle8/Oracle8.so
>> ./lib/site_perl/5.8.9/i686-linux/auto/DBD/Oracle8/Oracle8.bs
>> ./lib/site_perl/5.8.9/i686-linux/auto/DBD/Oracle8/Oracle8.h
>>
>> ( Oracle.pm is oracle 10 & Oracle8.pm is oracle 8 )
>>
>> I'm reading from a single tns_names.ora.
>> ( SERV2 is Oracle 10 & SERV1 is Oracle 8 )
>> ORACLE_HOME is the same each time.
>> LD_LIBRARY_PATH includes 2 entries - 1 for Oracle 10 lib directory
>> and 1 for Oracle 8.
>> So the environment is the same every time.
>>
>>
>> I can:
>> --------------------------------------------
>> use DBD::Oracle8;
>> my $db3=DBI->connect("dbi:Oracle8:SERV1",'','');
>> --------------------------------------------
>>
>> Or I can:
>> --------------------------------------------
>> use DBD::Oracle;
>> my $db3=DBI->connect("dbi:Oracle:SERV2",'','');
>> --------------------------------------------
>>
>> 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
>>
>> 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.
>>
>>
>> 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.
>>
>> Jeff
>
> I'd hope someone else can come up with a different solution to your
> problem but I'd be surprised if it worked as you have done it.
>
> I'm assuming the DBD::Oracle8 is linked against a different set of
> client libs to DBD::Oracle?
>
> For a start, the 2 oracle client libs will export a lot of the same
> symbols and so when you call oci_xxx where is it resolved - in the
> oracle 8 client or the other one. To make this work you'd need the
> dynamic linker to group the symbols and work down the group - I think it
> /may/ be worth setting PERL_DL_NONLAZY and exporting it (or whatever it
> is - run make test for DBD::Oracle and watch the output looking for the
> xxxLAZY environment variable). If this works it pretty much proves it
> but I'd still hope there is a better solution.
>
> I think you have probably entered a world of pain.
>
> Martin
>
>

Reply via email to