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
>
|
