This may indeed be impossible and I'm probably going to go with DBD::ProxyServer, but I want to add some interesting observations:
External connections Orcale 8: If the remoter server has a username that matches the username of the remote client it will still authenticate. This work in our setup. You don't necessarily have to be local. >From what I have seen Oracle.pm & Oracle.so will search LD_LIBRARY_PATH for the appropriate libclntsh.so that they were built with. Both builds will load happily if I have both versions of libclntsh.so in the path. If I take one away the corresponding Oracle.pm will complain on bootstrap and die. In fact, as I stated, using 2 Oracle.pms ( one hacked and built with 8 & the other NOT hacked and built with 10 ) --> if the Oracle8 connection is made first ( no username/password given & set up with external connections on a remote server) and then the Oracle10 connection ( again no username/password given & using the wallet ) - both connection are happy ........ until cleanup time on exit. Therefore if seemed to me that the only major thing ORACLE_HOME is being used for is tnsnames.ora On Thu, 2009-10-29 at 13:49 +0000, Charles Jardine wrote: > On 29/10/09 09:15, jeff wrote: > > Asked a question yesterday but I don't think I worded it very well so > > heres another try. > > > > I want to do an 'external connection' (i.e., No user or password > > supplied in DBI->connect ) from a single script to multiple versions of > > Oracle ( Oracle 8 & 10 ). > > > > What I have found so far is that Oracle.pm built againt the 10 client > > works great with the wallet (No user or password supplied in > > DBI->connect ) but will not connect to 8 without a username/password. > > > > Oracle.pm built against 8 works great with Oracle 8 when doing an > > 'external connection' (i.e., No user or password supplied in > > DBI->connect ) but will not connect to 10 without a username/password. > > > > Each version of Oracle uses a different mechanism to do an 'external > > connect' and they seem to have opted for NO backward compatibility in > > this regard. > > Executive summary: It can't be done in this way at all. > You have to user two different processes. Try DBD::Gofer. > > Longer explanation: > > The connection between an Oracle client and an Oracle server is > via an 'adapter'. Most adapters are network based. One, in > particular, is not. It is called the 'bequeather', or BEQ. > > The bequeather can be used only when the client is on the same > computer as the server. To use the bequeather, set ORACLE_SID > and ORACLE_HOME, unset TWO_TASK, and do not pass a connect > string with the login credentials. > > The bequeather is only designed to work when the client and server > are using the *same* ORACLE_HOME. It is not a matter of versions. > Even if you have two ORACLE_HOMEs of the same version, you have > to use the one which the server runs from. > > External authentication can be used only in conjunction with > bequeather connections. An 'identified externally' user can > log in without providing either a username or a password, provided > the Oracle username is equal to the concatenation of the > os_authent_prefix parameter and the OS username. In your > case, where the os_authent_prefix is null this means > the two usernames must be equal. > > Users 'identified externally' do not have passwords, and > can this only log in from the same computer as the server. > > This is all very convenient until you want to use databases > of different versions at once > > Is simply isn't possible to user two ORACLE_HOMEs at once > in a single process. Clashing linker names in the libraries > will cause segfaults etc.. > > You have to find a way of establishing your two connections > in different processes. >
