Re: [cx-oracle-users] Re: Choosing client libraries

[Anthony T. <ant...@gm...>]

On 1/24/06, Paul Watson <pw...@re...> wrote:
> Anthony:
>
> Yes, I realize that this is very Windows specific.  I usually have Oracle=
 on Solaris or AIX, but you know which OS is on the client.  Developer tool=
s sometimes do Windows specific things because 1) there are so many of them=
 and 2) the Winodws user (and frequently Windows developers) are least like=
ly to be able to handle technical problems.

I understand this and have no fundamental objection to something very
OS specific if it solves a problem cleanly (this is a relative term
since cross platform issues are rarely clean). In this case, however,
I'm not sure there would be any benefit. See below.

> Is the source code of the external program part of the cx_Oracle kit?  If=
 so, would it be acceptable if I suggested a patch?  Any hints as to the mo=
st relevant filename(s) involved?

It is part of the cx_OracleDBATools project which is available at
http://starship.python.net/crew/atuining. Having such logic as part of
cx_Oracle would not very helpful, I believe. The reason is that
currently cx_Oracle is linked directly. In other words, the symbol
OCISessionGet in the library oci.dll is referenced directly in the
cx_Oracle source, not dynamically. To do what you suggest would
involve searching the directories as I suggested above looking for
which client version is currently installed and then dynamically link
at runtime (as opposed to compile time) to the relevant symbols. To
understand what I mean, try loading a cx_Oracle module compiled
against Oracle 9i with an Oracle 8i client. You will get a messagebox
indicating that the symbol OCISessionGet could not be located in
oci.dll. If you have a suggestion about how to get around that problem
__without__ involving a huge rewrite of cx_Oracle to call everything
dynamically I'm all ears. :-) That's why I suggested doing something
like the following in pure Python:

driver =3D None
drivers =3D [
        ("8i", "oraclient8.dll"),
        ("9i", "oraclient9.dll"),
        ("10g", "oraclient10.dll")
]
for dir in os.environ["PATH"].split(os.pathsep):
    for driverSuffix, clientFileName in drivers:
        if os.path.exists(os.path.join(dir, clientFileName)):
            moduleName =3D "cx_Oracle_%s" % driverSuffix
            driver =3D sys.modules["cx_Oracle"] =3D __import__(moduleName)
            break
if not found:
    raise "COULD NOT FIND ORACLE CLIENT INSTALLATION!"

Proceed as normal from this point forward. I think this solves your
problem and is simple to implement. And integrating this into
cx_Oracle would be very difficult to say the least -- unless I'm
missing something, of course. Does that answer your question
satisfactorily?

> >  Date: Mon, 23 Jan 2006 07:46:40 -0700
> >  From: Anthony Tuininga <ant...@gm...>
> >  To: cx-...@li...
> >  Subject: Re: [cx-oracle-users] Choosing client libraries
> >  Reply-To: cx-...@li...
> >
> >  I thought I was trying to help you?? :-)
> >
> >  I currently look for oraclient.dll in $ORACLE_HOME/bin on Windows and
> >  for libclient.a in $ORACLE_HOME/lib on all other platforms. What you
> >  suggest would be very Windows specific and cx_Oracle runs on a lot
> >  more platforms than Windows. In addition, this is done by an external
> >  program, not as part of the cx_Oracle module itself.
> >
> >  So did I answer your original question satisfactorily? Or have you
> >  moved on since then??
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>