Re: Success ! Different versions of Oracle .so files within single Perl build

[Scott Smith]

Great.  Glad it works for you!

jeff wrote:

Thank you, Scott !

In case anyone else needs this sort of setup: I wanted to share this
quick & dirty &  successful test using Scott's RMI to connect to both
oracle 10 with a wallet and oracle 8 with external authentication - no
user names or passwords provided in script.

ora8_lib contains the Oracle DBD for oracle 8 and only the forked server
sees it.  ld_library_path is also set to pick up both oracle clients.
And prepare returns the query info as well - which is why proxyserver
didn't work for me.

looking very good so far !




use RMI::Client::ForkedPipes;
use DBI;


$c = RMI::Client::ForkedPipes->new(); 
$c->call_use('DBI');


my $paths = $c->call_eval('@main::x = @INC; return \...@main::x;');
foreach my $path (@{$paths}) {
print "$path\n";
}

print "\n";

$c->call_use_lib('/home/owuser1/perl58/perl_ora10/ora8_lib'); # A build
of Oracle DBD using oracle 8 client


my $paths = $c->call_eval('@main::x = @INC; return \...@main::x;');
foreach my $path (@{$paths}) {
print "$path\n";
}

print "\n";



$remote_dbh =
$c->call_class_method('DBI','connect',"dbi:Oracle:OWSERV1",'','');
print "$remote_dbh\n";
if (defined $remote_dbh) {
my $sth = $remote_dbh->prepare("select
sys_context('userenv','session_user') from dual");
foreach my $name (@{$sth->{NAME}}) {
print "\t$name\n";
}
$sth->execute;
print $sth->fetch;
print "  OK :) Oracle8\n";



} else {
print "No Connection Oracle8\n";
} 
$remote_dbh->disconnect;





my $db3=DBI->connect("dbi:Oracle:OWSERV2",'','');
print "$db3\n";
if (defined $db3) {
my $sth = $db3->prepare("select sys_context('userenv','session_user')
from dual");
foreach my $name (@{$sth->{NAME}}) {
print "\t$name\n";
}
$sth->execute;
print $sth->fetch;
print "  OK :) Oracle10\n";



} else {
print "No Connection Oracle10\n";
} 
$db3->disconnect;




$remote_dbh =
$c->call_class_method('DBI','connect',"dbi:Oracle:OWSERV1",'','');
print "$remote_dbh\n";
if (defined $remote_dbh) {
my $sth = $remote_dbh->prepare("select
sys_context('userenv','session_user') from dual");
foreach my $name (@{$sth->{NAME}}) {
print "\t$name\n";
}
$sth->execute;
print $sth->fetch;
print "  OK :) Oracle8\n";



} else {
print "No Connection Oracle8\n";
} 
$remote_dbh->disconnect;





  

On Mon, 2009-12-14 at 20:09 -0600, Scott Smith wrote:

Try RMI::Client::ForkedPipes.  Have the child process use one lib, and 
the parent use the other.  The child can give back with one DBI/DBD, and 
the parent can produce handles from the other.


This is effectively the proxy solution, but you're just forking and 
proxying to a private sub-process you created.


(Full disclosure: I wrote the RMI modules.  If they break for you please 
email me.)


Scott
  

Re: data retrieved from database is unexpectedly tainted

[Tim Bunce]

On Tue, Dec 15, 2009 at 04:17:42PM +, Martin Evans wrote:
> >>
> >> I've no idea what is tainting the returned data but this is reproducible
> >> for us here is a small amount of perl.
> > 
> > From memory, perl tainting works on a per-statement basis. If a tainted
> > value is accessed during a statement then any new values created by that
> > statement are marked as tainted. The 'tainted value seen' flag gets
> > reset for each statement.
> > 
> > So I'd guess that you're using a single statement, like a select*_*
> > method, to pass the (tained) SQL in and get the result data back.
> 
> I saw that "single statement" mechanism you refer to and there are
> references to it in DBI.xs too. I presumed it was talking about perl
> statements and not DBI statement handles. However, in this case I was
> not using a perl single statement I was doing (and can continue to
> demonstrate):
> 
> prepare($sql) <-- tained data went in here
> execute
> fetchall_arrayref

Tainting is viral. So I'd guess that the new sth and/or attributes etc.
created by prepare() are tainted. When they're referenced by fetch*()
then the result will be tainted.

> Also, I continue to do the same thing I always have in 5.8.8 with the
> same module versions where this does not happen so I'm really saying
> something seems to have changed between 5.8.8 and 5.10 and possibly in
> Perl itself.

Probably. Seems like a bug fix. (Arguably the DBI's TaintIn/TaintOut
attributes were workarounds for perl not doing the right thing itself.)

http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perl5100delta.pod
Mentions tainting a couple of times, but nothing obviously matches.

Tim.

Re: "Help saving MySQL"

[Tim Bunce]

On Tue, Dec 15, 2009 at 07:06:50AM -0700, Mike Howard wrote:
> So, how do we write to the Eurpoean Commission? Do they have an address?

In Monty's post he says:

Send this to: comp-merger-regis...@ec.europa.eu
If you want to keep us updated, send a copy to e...@askmonty.org

Tim.

> Tim Bunce wrote:
>> Michael “Monty” Widenius, the creator of MySQL, has asked me, among many
>> others, to help spread the word about an imminent decision by the
>> European Commission on the Oracle merger with Sun.
>>
>> Why should you care? Monty’s view, along with others like
>> http://keionline.org/ec-mysql is that Oracle has much more to gain from
>> neglecting MySQL than it has to gain from enhancing it.
>> (A slow strangling seems most likely. Note that "just fork a GPL MySQL"
>> is not really a viable option - see Monty's post.)
>>
>> Why should you act now? It seems that “Oracle has instead contacted
>> hundreds of their big customers and asked them to write to the EC and
>> require unconditional acceptance of the deal.” To balance this the
>> European Commission needs to hear voices from the other side of the
>> story. The European Commission is due to make a decision in just a
>> couple of weeks.
>>
>> What should you do? Read Monty’s post at
>> http://monty-says.blogspot.com/2009/12/help-saving-mysql.html
>> and act on it, if you so choose.
>>
>> If you work for a company that makes use of MySQL then please make sure
>> the relevant managers are aware of the issues.
>>
>> Tim.
>>
>>   
>

RE: DBD::DB2 on Windows with Strawberry Perl

[Thakore, Kartik]

I have managed to get DBD::DB2 using the ppm install. But now when I use:


I get this error.
H:\>perl db2.pl
Your vendor has not defined DBD::DB2::Constants macro SQL_PARAM_INPUT_OUTPUT at 
C:/strawberry/perl/site/lib/DBD/DB2.pm line 40
Compilation failed in require at db2.pl line 3.
BEGIN failed--compilation aborted at db2.pl line 3.


Db2.pl is

  use DBI;
  use DBD::DB2::Constants;
  use DBD::DB2;
  my $db = 'x';
  my $hostname ='x;
  my $port = 5;

   my $string = "dbi:DB2:DATABASE=$db; HOSTNAME=$hostname;";
  $dbh = DBI->connect($string, xx', 'xx') || die "Connection failed 
with error: $DBI::errstr";





From: Thakore, Kartik
Sent: Monday, December 14, 2009 3:17 PM
To: 'dbi-users@perl.org'
Subject: DBD::DB2 on Windows with Strawberry Perl

Hello,

I am trying to install DBD::DB2 on windows and I have IBM Express-C installed. 
Here is the error I receive:

cpan DBD::DB2


Database was generated on Mon, 14 Dec 2009 14:20:38 GMT
Running install for module 'DBD::DB2'
Running make for I/IB/IBMTORDB2/DBD-DB2-1.76.tar.gz
Checksum for C:\strawberry\cpan\sources\authors\id\I\IB\IBMTORDB2\DBD-DB2-1.76.t
ar.gz ok

  CPAN.pm: Going to build I/IB/IBMTORDB2/DBD-DB2-1.76.tar.gz


Configuring DBD::DB2...
Remember to actually read the README and CAVEATS files!

Using DB2 in "c:/strawberry/c"
System: perl5.01 DBI1.609 Win32 strawberryperl 5.10.0.6 #1 Mon Jul 20 00:01:
14 2009 i386 MSWin32-x86-multi-thread dl_win32.xs
Compiler: gcc -s -O2  -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX
Includes:  -I"c:/strawberry/c/include" -I"C:\strawberry\perl\site\lib/auto/DBI"
-I"C:\strawberry\perl\lib/auto/DBI" -I"C:\strawberry\perl\site\lib/auto/DBI"
Libraries: -L"c:/strawberry/c/lib" db2cli.lib db2api.lib -L"C:/PROGRA~1/IBM/SQLL
IB/LIB"

Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for db2cli.lib
Note (probably harmless): No library found for db2api.lib
Checking if your kit is complete...
Looks good
Writing Makefile for DBD::DB2::Constants
Writing Makefile for DBD::DB2
cp DB2.pm blib\lib\DBD\DB2.pm
cp lib/Bundle/DBD/DB2.pm blib\lib\Bundle\DBD\DB2.pm
cp DB2.pod blib\lib\DBD\DB2.pod
cp Constants.pm ..\blib\lib\DBD\DB2\Constants.pm
AutoSplitting ..\blib\lib\DBD\DB2\Constants.pm (..\blib\lib\auto\DBD\DB2\Constan
ts)
C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp  -typemap
 C:\strawberry\perl\lib\ExtUtils\typemap  Constants.xs > Constants.xsc && C:\str
awberry\perl\bin\perl.exe -MExtUtils::Command -e "mv" -- Constants.xsc Constants
.c
gcc -c  -I"c:/strawberry/c/include" -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_
IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX
-s -O2-DVERSION=\"1.76\"-DXS_VERSION=\"1.76\"  "-IC:\strawberry\perl\lib
\CORE"   Constants.c
Running Mkbootstrap for DBD::DB2::Constants ()
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e "chmod" -- 644 Constants.
bs
C:\strawberry\perl\bin\perl.exe -MExtUtils::Mksymlists \
 -e "Mksymlists('NAME'=>\"DBD::DB2::Constants\", 'DLBASE' => 'Constants', 'D
L_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  }, 'DL_VARS' => []);"
dlltool --def Constants.def --output-exp dll.exp
g++ -o ..\blib\arch\auto\DBD\DB2\Constants\Constants.dll -Wl,--base-file -Wl,dll
.base -mdll -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib" Constants
.o -Wl,--image-base,0x370e  C:\strawberry\perl\lib\CORE\libperl510.a -lmsvcr
t -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshel
l32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc
32 -lodbccp32 dll.exp
dlltool --def Constants.def --base-file dll.base --output-exp dll.exp
g++ -o ..\blib\arch\auto\DBD\DB2\Constants\Constants.dll -mdll -s -L"C:\strawber
ry\perl\lib\CORE" -L"C:\strawberry\c\lib" Constants.o -Wl,--image-base,0x370e000
0  C:\strawberry\perl\lib\CORE\libperl510.a -lmsvcrt -lmoldname -lkernel32 -luse
r32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lneta
pi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 dll.exp
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e "chmod" -- 755 ..\blib\ar
ch\auto\DBD\DB2\Constants\Constants.dll
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e "cp" -- Constants.bs ..\b
lib\arch\auto\DBD\DB2\Constants\Constants.bs
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e "chmod" -- 644 ..\blib\ar
ch\auto\DBD\DB2\Constants\Constants.bs
C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp  -typemap
 C:\strawberry\perl\lib\ExtUtils\typemap  DB2.xs > DB2.xsc && C:\strawberry\perl
\bin\perl.exe -MExtUtils::Command -e "mv" -- DB2.xsc DB2.c
gcc -c  -I"c:/strawberry/c/include" -I"C:\strawberry\perl\site\lib/auto/DBI" -I"
C:\strawberry\perl\lib/auto/DBI" -I"C:\strawberry\perl\site\lib/auto/DBI"
-s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_IMPLICI

Re: "Help saving MySQL"

[Mike Howard]

So, how do we write to the Eurpoean Commission? Do they have an address?

Tim Bunce wrote:

Michael “Monty” Widenius, the creator of MySQL, has asked me, among many
others, to help spread the word about an imminent decision by the
European Commission on the Oracle merger with Sun.

Why should you care? Monty’s view, along with others like
http://keionline.org/ec-mysql is that Oracle has much more to gain from
neglecting MySQL than it has to gain from enhancing it.
(A slow strangling seems most likely. Note that "just fork a GPL MySQL"
is not really a viable option - see Monty's post.)

Why should you act now? It seems that “Oracle has instead contacted
hundreds of their big customers and asked them to write to the EC and
require unconditional acceptance of the deal.” To balance this the
European Commission needs to hear voices from the other side of the
story. The European Commission is due to make a decision in just a
couple of weeks.

What should you do? Read Monty’s post at
http://monty-says.blogspot.com/2009/12/help-saving-mysql.html
and act on it, if you so choose.

If you work for a company that makes use of MySQL then please make sure
the relevant managers are aware of the issues.

Tim.

  

Re: data retrieved from database is unexpectedly tainted

[Martin Evans]

Tim Bunce wrote:
> On Tue, Dec 15, 2009 at 02:53:03PM +, Martin Evans wrote:
>> If you are using the latest DBI and Perl 5.10.0 or 5.10.1 and running in
>> taint mode (but have not set DBI's Taint, TainTIn, TaintOut) then use
>> tainted strings in the SQL you issue the resulting data is tainted. All
>> we were doing is adding $0 as a comment to the end of the SQL e.g., like
>> this:
>>
>> select * from table -- myprogram.pl
>>
>> but $0 is tainted and so all data coming back from the select is tainted.
>>
>> We moved our application from Perl 5.8.8 to an ubuntu box running 5.10.0
>> a few weeks ago but did not notice this problem until late last week.
>> This did not occur for us on 5.8.8 on another machine.
>>
>> I've no idea what is tainting the returned data but this is reproducible
>> for us here is a small amount of perl.
> 
> From memory, perl tainting works on a per-statement basis. If a tainted
> value is accessed during a statement then any new values created by that
> statement are marked as tainted. The 'tainted value seen' flag gets
> reset for each statement.
> 
> So I'd guess that you're using a single statement, like a select*_*
> method, to pass the (tained) SQL in and get the result data back.
> 
> Tim.
> 
> 

I saw that "single statement" mechanism you refer to and there are
references to it in DBI.xs too. I presumed it was talking about perl
statements and not DBI statement handles. However, in this case I was
not using a perl single statement I was doing (and can continue to
demonstrate):

prepare($sql) <-- tained data went in here
execute
fetchall_arrayref

Also, I continue to do the same thing I always have in 5.8.8 with the
same module versions where this does not happen so I'm really saying
something seems to have changed between 5.8.8 and 5.10 and possibly in
Perl itself.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: data retrieved from database is unexpectedly tainted

[Tim Bunce]

On Tue, Dec 15, 2009 at 02:53:03PM +, Martin Evans wrote:
> If you are using the latest DBI and Perl 5.10.0 or 5.10.1 and running in
> taint mode (but have not set DBI's Taint, TainTIn, TaintOut) then use
> tainted strings in the SQL you issue the resulting data is tainted. All
> we were doing is adding $0 as a comment to the end of the SQL e.g., like
> this:
> 
> select * from table -- myprogram.pl
> 
> but $0 is tainted and so all data coming back from the select is tainted.
> 
> We moved our application from Perl 5.8.8 to an ubuntu box running 5.10.0
> a few weeks ago but did not notice this problem until late last week.
> This did not occur for us on 5.8.8 on another machine.
> 
> I've no idea what is tainting the returned data but this is reproducible
> for us here is a small amount of perl.

>From memory, perl tainting works on a per-statement basis. If a tainted
value is accessed during a statement then any new values created by that
statement are marked as tainted. The 'tainted value seen' flag gets
reset for each statement.

So I'd guess that you're using a single statement, like a select*_*
method, to pass the (tained) SQL in and get the result data back.

Tim.

Success ! Different versions of Oracle .so files within single Perl build

[jeff]

Thank you, Scott !

In case anyone else needs this sort of setup: I wanted to share this
quick & dirty &  successful test using Scott's RMI to connect to both
oracle 10 with a wallet and oracle 8 with external authentication - no
user names or passwords provided in script.

ora8_lib contains the Oracle DBD for oracle 8 and only the forked server
sees it.  ld_library_path is also set to pick up both oracle clients.
And prepare returns the query info as well - which is why proxyserver
didn't work for me.

looking very good so far !




use RMI::Client::ForkedPipes;
use DBI;


$c = RMI::Client::ForkedPipes->new(); 
$c->call_use('DBI');

my $paths = $c->call_eval('@main::x = @INC; return \...@main::x;');
foreach my $path (@{$paths}) {
print "$path\n";
}

print "\n";

$c->call_use_lib('/home/owuser1/perl58/perl_ora10/ora8_lib'); # A build
of Oracle DBD using oracle 8 client


my $paths = $c->call_eval('@main::x = @INC; return \...@main::x;');
foreach my $path (@{$paths}) {
print "$path\n";
}

print "\n";



$remote_dbh =
$c->call_class_method('DBI','connect',"dbi:Oracle:OWSERV1",'','');
print "$remote_dbh\n";
if (defined $remote_dbh) {
my $sth = $remote_dbh->prepare("select
sys_context('userenv','session_user') from dual");
foreach my $name (@{$sth->{NAME}}) {
print "\t$name\n";
}
$sth->execute;
print $sth->fetch;
print "  OK :) Oracle8\n";



} else {
print "No Connection Oracle8\n";
} 
$remote_dbh->disconnect;




my $db3=DBI->connect("dbi:Oracle:OWSERV2",'','');
print "$db3\n";
if (defined $db3) {
my $sth = $db3->prepare("select sys_context('userenv','session_user')
from dual");
foreach my $name (@{$sth->{NAME}}) {
print "\t$name\n";
}
$sth->execute;
print $sth->fetch;
print "  OK :) Oracle10\n";



} else {
print "No Connection Oracle10\n";
} 
$db3->disconnect;



$remote_dbh =
$c->call_class_method('DBI','connect',"dbi:Oracle:OWSERV1",'','');
print "$remote_dbh\n";
if (defined $remote_dbh) {
my $sth = $remote_dbh->prepare("select
sys_context('userenv','session_user') from dual");
foreach my $name (@{$sth->{NAME}}) {
print "\t$name\n";
}
$sth->execute;
print $sth->fetch;
print "  OK :) Oracle8\n";



} else {
print "No Connection Oracle8\n";
} 
$remote_dbh->disconnect;




> On Mon, 2009-12-14 at 20:09 -0600, Scott Smith wrote:
> > Try RMI::Client::ForkedPipes.  Have the child process use one lib, and 
> > the parent use the other.  The child can give back with one DBI/DBD, and 
> > the parent can produce handles from the other.
> > 
> > This is effectively the proxy solution, but you're just forking and 
> > proxying to a private sub-process you created.
> > 
> > (Full disclosure: I wrote the RMI modules.  If they break for you please 
> > email me.)
> > 
> > Scott
> 

Re: data retrieved from database is unexpectedly tainted

[Martin Evans]

Martin J. Evans wrote:
> Martin J. Evans wrote:
>> Hi,
>>
>> I've spent some time on this today and I am getting nowhere. Before I
>> redouble my efforts I thought I'd post here just in case anything rings
>> a bell with someone.
>>
>> We are using the latest DBI and DBD::Oracle to get data from an Oracle
>> data. All data is retrieved via  reference cursor returned from a
>> function or procedure. When our application starts work there is no
>> problem but part way through all of the returned data is inexplicably
>> tainted. This is a real PITA because of bugs in Locale::MakeText
>> (http://rt.cpan.org/Public/Bug/Display.html?id=40727) via the Perl bug
>> re pos not updated on \G in regexps
>> (http://rt.perl.org/rt3/Public/Bug/Display.html?id=27344) and in general
>> because some DB returned data is used to create filenames and because it
>> prevents us using -T (instead we are having to run -t).
>>
>> We are running the perl script as root but it makes no difference run as
>> a normal user. When tainted data is returned TaintIn, TaintOut and Taint
>> are all false on the connection handle and the statement handles are
>> created a fresh for each procedure/function call.
>>
>> I've tried with the Ubuntu 9.10 supplied 5.10 and a separate 5.10.1 I
>> built - no difference.
>>
>> Any ideas where to go next?
>>
>> Thanks
>>
>> Martin
>>
>>
> 
> I forgot to mention I stuck an printf and abort in _get_fbav where
> output data is tainted and this never seems to get called. However, my
> retrieved data is still tainted.
> 
> Martin
> 
> 

For those interested I've finally tracked this down and although there
is some logic to it there seems to be a worrying change in behaviour.

If you are using the latest DBI and Perl 5.10.0 or 5.10.1 and running in
taint mode (but have not set DBI's Taint, TainTIn, TaintOut) then use
tainted strings in the SQL you issue the resulting data is tainted. All
we were doing is adding $0 as a comment to the end of the SQL e.g., like
this:

select * from table -- myprogram.pl

but $0 is tainted and so all data coming back from the select is tainted.

We moved our application from Perl 5.8.8 to an ubuntu box running 5.10.0
a few weeks ago but did not notice this problem until late last week.
This did not occur for us on 5.8.8 on another machine.

I've no idea what is tainting the returned data but this is reproducible
for us here is a small amount of perl.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: Looking for clever solution: Different versions of Oracle .so files within single Perl build

[Scott Smith]

Try RMI::Client::ForkedPipes.  Have the child process use one lib, and 
the parent use the other.  The child can give back with one DBI/DBD, and 
the parent can produce handles from the other.


This is effectively the proxy solution, but you're just forking and 
proxying to a private sub-process you created.


(Full disclosure: I wrote the RMI modules.  If they break for you please 
email me.)


Scott

jeff wrote:

You make an incorrect assumption :-(
Not trying to fool anyone or hide my identity, just hoping for further
input. 


If you don't want to answer, then don't - but there is no need to be
nasty about it.  You shouldn't view people so negatively.

As it turns out, the proxyserver is not a solution  and database links
are not an option - Not allowed to create.


On Mon, 2009-12-14 at 20:54 +0100, Alexander Foken wrote:
  
OK, while you were busy creating new threads, I remembered that this 
problem was discussed some time ago on this mailing list.


I was about to mail you a link to that discussion for further 
information, like 
, but then 
I saw that that therad was also started by you. We gave you several 
pointers how to solve this problem, from using a specific oracle client 
over proxy solutions to database links. We told you that it is 
impossible to include two different Oracle client libraries into one 
process. And we told you that you do not need to include two different 
Oracle client libraries into one process.


Now, you ask basically the same question again, hoping that no body 
remembered that thread startet two months ago. Well, I did, and it seems 
you are resistant to consulting, both from Oracle experts and from 
experienced DBI users.


So, why do you waste our time?

Alexander

On 14.12.2009 13:18, jeff wrote:


I need to connect simultaneously to both Oracle 8 and oracle 10 from the
same script using 'external' connection (ie, no username or password). 
The Oracle libraries, from my experimentations, are not compatible for

external connections. Oracle 8 uses system ID and Oracle 10 uses wallet
and they do not overlap. 


I need to stress that this is NOT an option. I have no say in this
regardless of how insecure it may sound.  


Anyway, since Oracle DBD can only be built against 1 at a time , this
presents a problem.  I have been trying to use DBI Proxy in a PAR
standalone for Oracle 8 connections and the usual setup for Oracle 10
connections with some limited success.  


What would be ideal would be to have 2 different Oracle DBD connections
from within the same perl build.  Any suggestions or ideas for potential
solutions out there ?

Thanks.
Jeff

  
  

Re: Looking for clever solution: Different versions of Oracle .so files within single Perl build

[jeff]

Scott,

Would something like this be close:
##
$c = RMI::Client::ForkedPipes->new(); 

$c->call_use_lib($ENV{MY_PERL_INSTALL}.'/some/path/to/other/Oracle_module'); 
   # A build of Oracle DBD using oracle 8 client not normally in @INC

$c->call_use('DBI');

$remote_dbh = $c->call_function('DBI::connect',"dbi:Oracle:host=
$host;sid=$sid", $user, $passwd);
##


On Mon, 2009-12-14 at 20:09 -0600, Scott Smith wrote:
> Try RMI::Client::ForkedPipes.  Have the child process use one lib, and 
> the parent use the other.  The child can give back with one DBI/DBD, and 
> the parent can produce handles from the other.
> 
> This is effectively the proxy solution, but you're just forking and 
> proxying to a private sub-process you created.
> 
> (Full disclosure: I wrote the RMI modules.  If they break for you please 
> email me.)
> 
> Scott

Re: Looking for clever solution: Different versions of Oracle .so files within single Perl build

[jeff]

Just reading about RMI - sounds promising :-)
Thanks you very much.

On Mon, 2009-12-14 at 20:09 -0600, Scott Smith wrote:
> Try RMI::Client::ForkedPipes.  Have the child process use one lib, and 
> the parent use the other.  The child can give back with one DBI/DBD, and 
> the parent can produce handles from the other.
> 
> This is effectively the proxy solution, but you're just forking and 
> proxying to a private sub-process you created.
> 
> (Full disclosure: I wrote the RMI modules.  If they break for you please 
> email me.)
> 
> Scott
> 
> jeff wrote:
> > You make an incorrect assumption :-(
> > Not trying to fool anyone or hide my identity, just hoping for further
> > input. 
> >
> > If you don't want to answer, then don't - but there is no need to be
> > nasty about it.  You shouldn't view people so negatively.
> >
> > As it turns out, the proxyserver is not a solution  and database links
> > are not an option - Not allowed to create.
> >
> >
> > On Mon, 2009-12-14 at 20:54 +0100, Alexander Foken wrote:
> >   
> >> OK, while you were busy creating new threads, I remembered that this 
> >> problem was discussed some time ago on this mailing list.
> >>
> >> I was about to mail you a link to that discussion for further 
> >> information, like 
> >> , but then 
> >> I saw that that therad was also started by you. We gave you several 
> >> pointers how to solve this problem, from using a specific oracle client 
> >> over proxy solutions to database links. We told you that it is 
> >> impossible to include two different Oracle client libraries into one 
> >> process. And we told you that you do not need to include two different 
> >> Oracle client libraries into one process.
> >>
> >> Now, you ask basically the same question again, hoping that no body 
> >> remembered that thread startet two months ago. Well, I did, and it seems 
> >> you are resistant to consulting, both from Oracle experts and from 
> >> experienced DBI users.
> >>
> >> So, why do you waste our time?
> >>
> >> Alexander
> >>
> >> On 14.12.2009 13:18, jeff wrote:
> >> 
> >>> I need to connect simultaneously to both Oracle 8 and oracle 10 from the
> >>> same script using 'external' connection (ie, no username or password). 
> >>> The Oracle libraries, from my experimentations, are not compatible for
> >>> external connections. Oracle 8 uses system ID and Oracle 10 uses wallet
> >>> and they do not overlap. 
> >>>
> >>> I need to stress that this is NOT an option. I have no say in this
> >>> regardless of how insecure it may sound.  
> >>>
> >>> Anyway, since Oracle DBD can only be built against 1 at a time , this
> >>> presents a problem.  I have been trying to use DBI Proxy in a PAR
> >>> standalone for Oracle 8 connections and the usual setup for Oracle 10
> >>> connections with some limited success.  
> >>>
> >>> What would be ideal would be to have 2 different Oracle DBD connections
> >>> from within the same perl build.  Any suggestions or ideas for potential
> >>> solutions out there ?
> >>>
> >>> Thanks.
> >>> Jeff
> >>>
> >>>   
> >>>   
> >> 
> 
> 

Re: Looking for clever solution: Different versions of Oracle .so files within single Perl build

[Peter J. Holzer]

On 2009-12-14 07:18:41 -0500, jeff wrote:
> I need to connect simultaneously to both Oracle 8 and oracle 10 from the
> same script using 'external' connection (ie, no username or password). 
> The Oracle libraries, from my experimentations, are not compatible for
> external connections. Oracle 8 uses system ID and Oracle 10 uses wallet
> and they do not overlap. 
[...]
> Anyway, since Oracle DBD can only be built against 1 at a time , this
> presents a problem.  I have been trying to use DBI Proxy in a PAR
> standalone for Oracle 8 connections and the usual setup for Oracle 10
> connections with some limited success.  
> 
> What would be ideal would be to have 2 different Oracle DBD connections
> from within the same perl build.  Any suggestions or ideas for potential
> solutions out there ?

Split the script into two processes: One of them talks the Oracle 8 DB
and the other one talks to the Oracle 10 DB. Let them communicate over a
pipe or socket.

hp

-- 
   _  | Peter J. Holzer| Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR   | eingeprägt stehen: "Ein ewig Rätsel will ich
| |   | h...@wsr.ac.at  | bleiben, mir und andern."
__/   | http://www.hjp.at/ |-- Wolfram Heinrich in desd


signature.asc
Description: Digital signature