Thread: [cx-oracle-users] Choosing client libraries
Brought to you by:
atuining
Menu
▾
▴
cx-oracle-users
|
From: <pw...@re...> - 2006-01-20 22:15:37
|
Is there any way to control which client libraries will be used by cx_Oracle?
If the 8.1 client is used, then it cannot connect to XE or 10g.
If the XE client is used, then it cannot connect to 8.1.7.
When it fails, how can I give the user helpful information from which the problem might be resolved? Yes, I can handle an exception. What information should I give the user?
C:\src\python\db\cx_Oracle>test1.py
apilevel = 2.0
buildtime = January 26, 2005 14:37:48
version = HEAD
type = <type 'str'>
dsn = (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.168.80.80)(PORT=1521)))(CONNECT_DATA=(SID=TRAIN)))
Traceback (most recent call last):
File "C:\src\python\db\cx_Oracle\test1.py", line 15, in ?
connection = cx_Oracle.connect("pwatson", "***********", "TRAIN")
cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect identifier specified
|
|
From: <pw...@re...> - 2006-01-21 16:39:27
|
> Date: Fri, 20 Jan 2006 15:57:51 -0700 > From: Anthony Tuininga <ant...@gm...> > To: cx-...@li... > Subject: Re: [cx-oracle-users] Choosing client libraries > Reply-To: cx-...@li... > > Unfortunately Oracle does not provide the client version in its files > anywhere so that information cannot be provided directly. You can > check for the existence of certain attributes (like > cx_Oracle.SessionPool is only available in 9i and up and > cx_Oracle.Connection.module is only available in 10g and up) or > something similar but I'm not aware of any other method of doing this. > Recognize as well that since cx_Oracle is linked directly against the > Oracle client libraries these must be present in order to even import > the module. Windows seems to like to also put information in a message > box (very unhelpful for server applications) when an import fails > because of a linking problem. > > The only effective means I have found of dealing with this is found in > my cx_OracleDBATools package. I search $ORACLE_HOME/lib for files that > are only found in 8i, 9i or 10g and then specifically import > cx_Oracle_8i or cx_Oracle_9i or cx_Oracle_10g as cx_Oracle. In other > words, you need to have each module available as a separate name and > then decide which version you want to import yourself. The oci.dll library has the version information in the Windows VERSIONINFO structure. At least, in the 8.1.7 client and the beta XE server packages it does. This can be accessed through the win32 module or directly using ctypes. Does this help? |
|
From: Anthony T. <ant...@gm...> - 2006-01-23 14:53:53
|
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?? On 1/21/06, Paul Watson <pw...@re...> wrote: > > Date: Fri, 20 Jan 2006 15:57:51 -0700 > > From: Anthony Tuininga <ant...@gm...> > > To: cx-...@li... > > Subject: Re: [cx-oracle-users] Choosing client libraries > > Reply-To: cx-...@li... > > > > Unfortunately Oracle does not provide the client version in its files > > anywhere so that information cannot be provided directly. You can > > check for the existence of certain attributes (like > > cx_Oracle.SessionPool is only available in 9i and up and > > cx_Oracle.Connection.module is only available in 10g and up) or > > something similar but I'm not aware of any other method of doing this. > > Recognize as well that since cx_Oracle is linked directly against the > > Oracle client libraries these must be present in order to even import > > the module. Windows seems to like to also put information in a message > > box (very unhelpful for server applications) when an import fails > > because of a linking problem. > > > > The only effective means I have found of dealing with this is found in > > my cx_OracleDBATools package. I search $ORACLE_HOME/lib for files that > > are only found in 8i, 9i or 10g and then specifically import > > cx_Oracle_8i or cx_Oracle_9i or cx_Oracle_10g as cx_Oracle. In other > > words, you need to have each module available as a separate name and > > then decide which version you want to import yourself. > > The oci.dll library has the version information in the Windows VERSIONINF= O structure. At least, in the 8.1.7 client and the beta XE server packages= it does. This can be accessed through the win32 module or directly using = ctypes. > > Does this help? > > > ------------------------------------------------------- > 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 > |
|
From: <pw...@re...> - 2006-01-25 17:01:52
|
How can I know, at runtime, with which version of Oracle libs my cx_Oracle is linked? >>> print cx_Oracle.version HEAD >>> print cx_oracle.apilevel 2.0 >>> print cx_oracle.buildtime January 26, 2005 14:37:48 I am confused by your statement that cx_Oracle is linked to a specific Oracle client. If I have Oracle 8.1 client in the PATH when I run my Python script using cx_Oracle I can access an Oracle 8.1.7 running on an AIX box. If I have the Oracle XE directory in the PATH, I can access the Oracle 10g XE running on the local machine. With respect to the suggestion that cx_Oracle have a set of redirection calls to connect with the Oracle libs, I do not think that the overhead of a function call will be significant. |
|
From: Anthony T. <ant...@gm...> - 2006-01-25 23:27:14
|
On 1/25/06, Paul Watson <pw...@re...> wrote: > How can I know, at runtime, with which version of Oracle libs my cx_Oracl= e is linked? > > >>> print cx_Oracle.version > HEAD > >>> print cx_oracle.apilevel > 2.0 > >>> print cx_oracle.buildtime > January 26, 2005 14:37:48 You can't. I can guess by looking at the constants that are defined in the header files but Oracle does not indicate what client version is in use -- so it would only be a guess. BTW, the HEAD designation was accidentally left in for cx_Oracle 4.1.1. If you get cx_Oracle 4.1.2 it will give you the correct version. > I am confused by your statement that cx_Oracle is linked to a specific Or= acle client. If I have Oracle 8.1 client in the PATH when I run my Python = script using cx_Oracle I can access an Oracle 8.1.7 running on an AIX box. = If I have the Oracle XE directory in the PATH, I can access the Oracle 10g= XE running on the local machine. The version of the Oracle database to which you are connecting is not the issue. Its the client version that matters. On Windows, the DLL name is called oci.dll for all versions of Oracle so the link will fail if and only if you use a cx_Oracle build for (for example) Oracle 10g and then try to actually run it with an Oracle 8i client. If you have a cx_Oracle build for Oracle 8i you should be able to run it successfully against Oracle 9i and Oracle 10g clients since Oracle is usually fairly careful about their API. On Unix platforms the client library is named libclntsh.so.<VERSION> and can be determined by using ldd. Since the version is included in the name of the shared library you cannot run cx_Oracle compiled against 8i with an Oracle 9i client. Does that clear things up? Or make things even more confusing? :-) > With respect to the suggestion that cx_Oracle have a set of redirection c= alls to connect with the Oracle libs, I do not think that the overhead of a= function call will be significant. Probably not -- especially if all of the function pointers are stored in global memory so the effort of looking them up is only performed once. I'm still uncertain as to whether the effort is worth it or not....I'm still thinking about it. Any further input would be appreciated. > ------------------------------------------------------- > 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 > |
|
From: <pw...@re...> - 2006-01-27 11:53:57
|
> Ok, I can accept that the risks are reasonable. The only other > difference in behavior that I can think of is that some of the current > differences between OCI releases are based on #define constants -- > which are definitely not available in the dll. We will need to find > some function that exists in one release and not in the other and use > the presence of that function instead as a means of determining what > client level is being used. Are you volunteering to find those??? :-) > Are you volunteering to provide the template I should be using to try > this? How eager are you to move down this path? How about using the VERSIONINFO from oci.dll? I still do not understand your statement, Anthony, that cx_Oracle is linked to a specific version of Oracle client. I can use the same cx_Oracle with 10g and 8.1.7 by changing the PATH. There are three components with "version" states. If cx_Oracle executable does a static link to one version of the Oracle client library, then how can I use the same cx_Oracle to connect with both 8.1.7 and 10g? cx_Oracle Oracle client Oracle database |
|
From: Anthony T. <ant...@gm...> - 2006-01-27 14:55:33
|
On 1/27/06, Paul Watson <pw...@re...> wrote: > > Ok, I can accept that the risks are reasonable. The only other > > difference in behavior that I can think of is that some of the current > > differences between OCI releases are based on #define constants -- > > which are definitely not available in the dll. We will need to find > > some function that exists in one release and not in the other and use > > the presence of that function instead as a means of determining what > > client level is being used. Are you volunteering to find those??? :-) > > Are you volunteering to provide the template I should be using to try > > this? How eager are you to move down this path? > > How about using the VERSIONINFO from oci.dll? That's only available on Windows. cx_Oracle does run on other platforms -- what would you suggest for those platforms? > I still do not understand your statement, Anthony, that cx_Oracle is link= ed to a specific version of Oracle client. I can use the same cx_Oracle wi= th 10g and 8.1.7 by changing the PATH. There are three components with "ve= rsion" states. If cx_Oracle executable does a static link to one version o= f the Oracle client library, then how can I use the same cx_Oracle to conne= ct with both 8.1.7 and 10g? The binaries I am providing are indeed dynamically linked. As I have stated elsewhere in this thread, on Windows Oracle has named the DLL oci.dll so you can quite easily run modules compiled against __older__ Oracle clients in __newer__ Oracle clients without trouble. Running a module compiled against __newer__ Oracle clients with an __older__ Oracle client does __NOT__ work because new methods are referenced in the module and cannot be found in the dll. That's what I am referring to. On Unix platforms Oracle chose to include the basic version in the name of the shared library so you cannot mix and match there as easily. I believe this thread was supposed to be about removing even this restriction by dynamically looking up the methods to see if they exist -- currently that code is added automatically by the linker which is what I was trying to say. Obviously I haven't been very clear. :-) Hopefully this makes it clearer?? > cx_Oracle > Oracle client > Oracle database > > > ------------------------------------------------------- > 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 > |
|
From: Anthony T. <ant...@gm...> - 2006-01-20 22:57:54
|
Unfortunately Oracle does not provide the client version in its files
anywhere so that information cannot be provided directly. You can
check for the existence of certain attributes (like
cx_Oracle.SessionPool is only available in 9i and up and
cx_Oracle.Connection.module is only available in 10g and up) or
something similar but I'm not aware of any other method of doing this.
Recognize as well that since cx_Oracle is linked directly against the
Oracle client libraries these must be present in order to even import
the module. Windows seems to like to also put information in a message
box (very unhelpful for server applications) when an import fails
because of a linking problem.
The only effective means I have found of dealing with this is found in
my cx_OracleDBATools package. I search $ORACLE_HOME/lib for files that
are only found in 8i, 9i or 10g and then specifically import
cx_Oracle_8i or cx_Oracle_9i or cx_Oracle_10g as cx_Oracle. In other
words, you need to have each module available as a separate name and
then decide which version you want to import yourself.
Hope this helps.
On 1/20/06, Paul Watson <pw...@re...> wrote:
> Is there any way to control which client libraries will be used by cx_Ora=
cle?
>
> If the 8.1 client is used, then it cannot connect to XE or 10g.
> If the XE client is used, then it cannot connect to 8.1.7.
>
> When it fails, how can I give the user helpful information from which the=
problem might be resolved? Yes, I can handle an exception. What informat=
ion should I give the user?
>
> C:\src\python\db\cx_Oracle>test1.py
> apilevel =3D 2.0
> buildtime =3D January 26, 2005 14:37:48
> version =3D HEAD
> type =3D <type 'str'>
> dsn =3D (DESCRIPTION=3D(ADDRESS_LIST=3D(ADDRESS=3D(PROTOCOL=3DTCP)(HOST=
=3D172.168.80.80)(PORT=3D1521)))(CONNECT_DATA=3D(SID=3DTRAIN)))
> Traceback (most recent call last):
> File "C:\src\python\db\cx_Oracle\test1.py", line 15, in ?
> connection =3D cx_Oracle.connect("pwatson", "***********", "TRAIN")
> cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect ide=
ntifier specified
>
>
> -------------------------------------------------------
> 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
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X