Thread: [cx-oracle-users] Strange TNS issue with new build of cx_Oracle.so
Brought to you by:
atuining
From: Michael S. <mic...@ho...> - 2008-07-10 15:02:57
|
Hi Here's the platform(s) Sun Sparc running Solaris Sun Opteron running Solaris Database(s) Oracle 9i and Oracle 10g (10.1) and(10.2) Python version 2.4.2 on Sparc, version 2.5.0 on Opteron I've downloaded the cx_Oracle version 4.4 source code. I'm trying to build this for Oracle 10g in a (10.2) environment. I have TNS_ADMIN, ORACLE_HOME both set. LD_LIBRARY_PATH gets set based on the platform. Because we need to have python support 9i, 10g and probably 11i in a couple of months, we keep the cx_Oracle.so in a different directory than the site-packages subdirectory and then include it in my PYTHONPATH and LD_LIBRARY_PATH. When I start up python (2.4.2) on Sparc, this works fine and everyone is happy. When I start up python (2.5.0) on Opteron, I can import cx_Oracle, but when I try to get a connection using the cx_Oracle.Connection() method, I get a TNS error. If I use the cx_Oracle.makedsn() and then use the cx_Oracle.connect(), I can get a connection. (This method bypasses the check in the local tnsnames.ora file) So what am I missing? Whatwould cause cx_Oracle to fail its TNS check? TIA -Mike _________________________________________________________________ It’s a talkathon – but it’s not just talk. http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk |
From: Anthony T. <ant...@gm...> - 2008-07-10 19:58:22
|
First, what TNS error? Second, check to see what the makedsn() returns and compare with what is stored in your tnsnames.ora file. I can think of no reason why the new version of cx_Oracle would have a problem compared to the old version. Anthony On Thu, Jul 10, 2008 at 9:02 AM, Michael Segel <mic...@ho...> wrote: > Hi > Here's the platform(s) > > Sun Sparc running Solaris > Sun Opteron running Solaris > > Database(s) Oracle 9i and Oracle 10g (10.1) and(10.2) > > Python version 2.4.2 on Sparc, version 2.5.0 on Opteron > > I've downloaded the cx_Oracle version 4.4 source code. > I'm trying to build this for Oracle 10g in a (10.2) environment. > > I have TNS_ADMIN, ORACLE_HOME both set. > LD_LIBRARY_PATH gets set based on the platform. > > Because we need to have python support 9i, 10g and probably 11i in a couple > of months, > we keep the cx_Oracle.so in a different directory than the site-packages > subdirectory and then include it in my PYTHONPATH and LD_LIBRARY_PATH. > > When I start up python (2.4.2) on Sparc, this works fine and everyone is > happy. > When I start up python (2.5.0) on Opteron, I can import cx_Oracle, but when > I try to get a connection using the > cx_Oracle.Connection() method, I get a TNS error. > > If I use the cx_Oracle.makedsn() and then use the cx_Oracle.connect(), I can > get a connection. > (This method bypasses the check in the local tnsnames.ora file) > > So what am I missing? > > Whatwould cause cx_Oracle to fail its TNS check? > > TIA > > -Mike > > ________________________________ > It's a talkathon – but it's not just talk. Check out the i'm Talkathon. > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > cx-oracle-users mailing list > cx-...@li... > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users > > |
From: Michael S. <mic...@ho...> - 2008-07-10 20:03:14
|
Thanks for the response. makedsn() matches the tnsnames.ora sans some formatting. That's why I'm confused. I mean you're right if I can use makedsn() and get a connection, then I should be ok. The only thing that one of my coworkers thought of was that everything (python and cx_Oracle) were compiled as 32 bit versions even though the opteron is a 64 bit machine. Though that there was something in the archieves on this issue. I'm currently downloading 2.5.2 and trying to make a complete clean build. Thanks again! -Mike > Date: Thu, 10 Jul 2008 13:58:19 -0600> From: ant...@gm...> To: cx-...@li...> Subject: Re: [cx-oracle-users] Strange TNS issue with new build of cx_Oracle.so> > First, what TNS error? Second, check to see what the makedsn() returns> and compare with what is stored in your tnsnames.ora file. I can think> of no reason why the new version of cx_Oracle would have a problem> compared to the old version.> > Anthony> > On Thu, Jul 10, 2008 at 9:02 AM, Michael Segel> <mic...@ho...> wrote:> > Hi> > Here's the platform(s)> >> > Sun Sparc running Solaris> > Sun Opteron running Solaris> >> > Database(s) Oracle 9i and Oracle 10g (10.1) and(10.2)> >> > Python version 2.4.2 on Sparc, version 2.5.0 on Opteron> >> > I've downloaded the cx_Oracle version 4.4 source code.> > I'm trying to build this for Oracle 10g in a (10.2) environment.> >> > I have TNS_ADMIN, ORACLE_HOME both set.> > LD_LIBRARY_PATH gets set based on the platform.> >> > Because we need to have python support 9i, 10g and probably 11i in a couple> > of months,> > we keep the cx_Oracle.so in a different directory than the site-packages> > subdirectory and then include it in my PYTHONPATH and LD_LIBRARY_PATH.> >> > When I start up python (2.4.2) on Sparc, this works fine and everyone is> > happy.> > When I start up python (2.5.0) on Opteron, I can import cx_Oracle, but when> > I try to get a connection using the> > cx_Oracle.Connection() method, I get a TNS error.> >> > If I use the cx_Oracle.makedsn() and then use the cx_Oracle.connect(), I can> > get a connection.> > (This method bypasses the check in the local tnsnames.ora file)> >> > So what am I missing?> >> > Whatwould cause cx_Oracle to fail its TNS check?> >> > TIA> >> > -Mike> >> > ________________________________> > It's a talkathon – but it's not just talk. Check out the i'm Talkathon.> > -------------------------------------------------------------------------> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!> > Studies have shown that voting for your favorite open source project,> > along with a healthy diet, reduces your potential for chronic lameness> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08> > _______________________________________________> > cx-oracle-users mailing list> > cx-...@li...> > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users> >> >> > -------------------------------------------------------------------------> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!> Studies have shown that voting for your favorite open source project,> along with a healthy diet, reduces your potential for chronic lameness> and boredom. Vote Now at http://www.sourceforge.net/community/cca08> _______________________________________________> cx-oracle-users mailing list> cx-...@li...> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users _________________________________________________________________ It’s a talkathon – but it’s not just talk. http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk |
From: Mark H. <mh...@pi...> - 2008-07-10 20:32:47
|
Anthony Tuininga wrote: > First, what TNS error? Second, check to see what the makedsn() returns > and compare with what is stored in your tnsnames.ora file. I can think > of no reason why the new version of cx_Oracle would have a problem > compared to the old version. It might not be a bad idea to run strace (on solaris, truss or dtruss?), just to make sure there's no oddness in which tnsnames is being read. |