Should Allways work for 1 DB version forward and one back. So a 10 instantshould should work a 9,10 and 11 at least that is the theory. Oracle is a little unclear on what a Version is. What I usually do is complie with the instant client and depoly it with the compiled code. This is how activestae gets awaywith it as they install the IC along with the dll so they need only compile it once/\. One can freely ditribute the IC with no gruff from Oracle. Cheers
> Date: Fri, 19 Apr 2013 08:35:39 +0100 > From: boh...@ntlworld.com > To: dbi-dev@perl.org > Subject: Re: Building DBD::Oracle with one version but deploying with another > > On 18/04/13 18:41, Jan Dubois wrote: > > Sorry, I can't remember the details. I think you must use clients for > > the same version of Oracle on the server, e.g. if you compiled > > DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to > > work with an Oracle 11 client. But my memories of that are foggy; I > > don't know if this is just a limitation on Windows, or if it applies > > everywhere. > > > > I also never tried to run DBD::Oracle compiled against the instant > > client with a server that has the regular client installed. I kind of > > expect it to work, if they are the same versions, but haven't verified > > it. > > > > Cheers, > > -Jan > > DBD::Oracle attempts to find the version of your client using sqlplus etc. > Once it knows the version it sets macros which affect what support is built > into DBD::Oracle. > > e.g., > > Installing on a linux, Ver#2.6 > Using Oracle in /home/martin/instantclient_11_2/ > DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR) > Oracle version 11.2.0.2 (11.2) > Looks like an Instant Client installation, okay > Your LD_LIBRARY_PATH env var is set to '/home/martin/instantclient_11_2/' > > DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" > -DORA_OCI_102 -DORA_OCI_112 > > Notice the ORA_OCI_102 and ORA_OCI_112 macros are defined in this case since > this was Oracle 11.2. If you search the source for those macros you'll see > loads of places where code is only included if they are defined and hence it > affects what you can do with DBD::Oracle. > > So if you built against a 10.2 client and then attempted to run against a > 11.2 client there are a) things you would not be able to do and b) possibly > DBD::Oracle would make a different set of OCI calls (you'd need to read the > code to see what). > > If you did it the other way around it is quite likely some things won't work. > > The instant client files required to run DBD::Oracle (as opposed to build it) > are quite small. What cannot you distribute those with the DBD::Oracle you > build. > > Martin > > > On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba <jrw32...@yahoo.com> wrote: > >> Yes, I'm doing that. Each server can have a different environment than the > >> server the original DBD:Oracle was built on. Or the question still applies > >> if I want to use a different version of Oracle installed on the original > >> build server, especially if I remove the version of Oracle that was used to > >> build the original DBD::Oracle. > >> > >> ________________________________ > >> From: Jan Dubois <j...@activestate.com> > >> To: John Wiersba <jrw32...@yahoo.com> > >> Cc: Lyle <webmas...@cosmicperl.com>; "dbi-dev@perl.org" <dbi-dev@perl.org> > >> Sent: Thursday, April 18, 2013 1:09 PM > >> > >> Subject: Re: Building DBD::Oracle with one version but deploying with > >> another > >> > >> I think you also need to add the ORACLE_HOME directory to > >> LD_LIBRARY_PATH (on the deployment machine) to make it work. > >> > >> Cheers, > >> -Jan > >> > >> On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba <jrw32...@yahoo.com> wrote: > >>> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for > >>> distribution to another server (assume the OS and perl versions on both > >>> servers) which will have a different ORACLE_HOME, possibly a different > >>> version of the Oracle client and likely in a different location. The > >>> target > >>> server may not have a C compiler. > >>> > >>> That's the same situation that ActiveState must have encountered, building > >>> DBD::Oracle with whatever version of Oracle they had downloaded and > >>> installed in some random location, but deploying it on the user's server > >>> which likely has a different version of Oracle installed in a different > >>> location. > >>> > >>> > >>> > >>> > >>>> ________________________________ > >>>> From: Lyle <webmas...@cosmicperl.com> > >>>> To: dbi-dev@perl.org > >>>> Sent: Thursday, April 18, 2013 11:43 AM > >>>> Subject: Re: Building DBD::Oracle with one version but deploying with > >>>> another > >>>> > >>>> > >>>> On 18/04/2013 16:22, John Wiersba wrote: > >>>>> [A previous version of this question was asked on dbi-users -- I haven't > >>>>> gotten any response there. Not sure which list to post to.] > >>>>> > >>>>> Hi, I'd like to find out how to build/install DBD::Oracle with one > >>>>> version of Oracle client but then deploy it with a potentially different > >>>>> client version, say on a server without the original client version (or > >>>>> with > >>>>> it installed in a different location). It seems like the Oracle > >>>>> client libraries can be loaded dynamically at runtime, based on > >>>>> ORACLE_HOME, so there doesn't need to be a dependency on those exact > >>>>> client libraries that were used at build/install time. > >>>>> > >>>>> Another > >>>>> way of asking: How does ActiveState deploy DBD::Oracle without needing > >>>>> to build it (maybe no C compiler is available), on servers with > >>>>> different versions of the Oracle client libraries installed? > >>>> > >>>> I built DBD::Oracle on windows recently. I did need the Oracle client > >>>> libraries for the tests to pass, and ActiveState would have too. Once > >>>> built > >>>> they package up the binaries for distribution, and expect the target > >>>> system > >>>> to have the appropriate libraries. If I remember correctly, I had to > >>>> download the appropriate libraries from Oracle. I spoke to the vanilla > >>>> Perl > >>>> people about this, as they currently don't have a DBD::Oracle bundled in > >>>> with their distro. They had been looking at bundling the client > >>>> libraries as > >>>> well, but I think there is a licensing issues surrounding doing that > >>>> which > >>>> is why ActiveState do not do it. We agreed to take another look at it > >>>> next > >>>> month as I'm very busy this month. > >>>> > >>>>> I've searched the archives for both dbi-dev and dbi-users and can't find > >>>>> this issue addressed, although I did see a similar issue asked once. If > >>>>> there's any reference material that I have overlooked, could you please > >>>>> point it out. The README for DBD::Oracle seems to indicate that this is > >>>>> not > >>>>> possible or not advised, but then what is ActiveState doing to make it > >>>>> work? > >>>> > >>>> With ActiveState's ppm, it wont work on the target system unless the > >>>> correct client libraries are there. I think that's what led me to build > >>>> my > >>>> own DBD::Oracle in the first place. I was building for 64 bit Windows, > >>>> and > >>>> found this blog post: > >>>> http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ > >>>> I found errors in that post and commented with my findings, yet my > >>>> comment > >>>> has yet to be accepted. I think Pythian is on this list? So maybe they > >>>> will > >>>> comment. > >>>> > >>>> > >>>> Lyle > >>>> > >>>> > >>>> > >>>> > >> > >> >
