cx-oracle-users — Primary discussion list for users (and developers) of cx_Oracle

RE: [cx-oracle-users] Segmentation Fault

[Branimir P. <Bra...@cp...>]

>Need I other libraries?
>When I installed the full oracle client all works correctly...

At place I work at we had the similar idea - to include only few 
needed items from Oracle Client install, in order to avoid the 
rest of the bloat and we also faced similar problems. We then asked 
Oracle for help in hunting/pinpointing what's needed and what can 
safely be ignored and got somewhat surprising answer that although 
that would be technically possible we are NOT allowed to do so. 
Apparently some "fine print" explicitly forbids taking just few 
selected pieces from Oracle Client, instead you must install ALL 
that comes with it or else license to use the client is violated.
To stay on the "safe side" we have to keep installing full 300+MB 
of Oracle Client (9i) in order to be able to run our app that is
1/6 in size. Does not make sense, but - that's how it has to be...

Branimir

Re: [cx-oracle-users] Segmentation Fault

[Anthony T. <an...@co...>]

No idea. I know that Oracle is planning a stripped down version of the
Oracle client (with a minimal number of files like you have here) for
10g so when that is released you might want to take a look at it and see
if you can't do the same for Oracle 9i.

I can give a couple of suggestions for things that I would try but no
guarantees that any of this will work. :-)

1) Execute ldd on the binaries and make sure that there are no missing
libraries.

2) Run strace on your program and see whether that gives you any useful
information (such as files it is attempting to open but can't find, for
example)

3) Take a full client installation and continue paring files away until
you find the minimal set that works.

Have fun... :-)

On Thu, 2003-12-18 at 04:19, Antonio Beamud Montero wrote:
> Hi all:
> I'm developing some python utilities and this utilities need to get/set
> information from a Oracle D.B.
> I have packed the oracle client libraries in a RPM with this files:
> 
> /opt/oracle/client_libs/lib/libclntsh.so.9.0
> /opt/oracle/client_libs/lib/libwtc9.so
> /opt/oracle/client_libs/network/admin/tnsnames.ora
> /opt/oracle/client_libs/oracore/zoneinfo/timezlrg.dat
> /opt/oracle/client_libs/oracore/zoneinfo/timezone.dat
> /opt/oracle/client_libs/rdbms/mesg/bbede.msb
> /opt/oracle/client_libs/rdbms/mesg/bbedus.msb
> /opt/oracle/client_libs/rdbms/mesg/bbedus.msg
> /opt/oracle/client_libs/rdbms/mesg/dbve.msb
> /opt/oracle/client_libs/rdbms/mesg/dbvus.msb
> /opt/oracle/client_libs/rdbms/mesg/dbvus.msg
> /opt/oracle/client_libs/rdbms/mesg/expe.msb
> /opt/oracle/client_libs/rdbms/mesg/expus.msb
> /opt/oracle/client_libs/rdbms/mesg/expus.msg
> /opt/oracle/client_libs/rdbms/mesg/impe.msb
> /opt/oracle/client_libs/rdbms/mesg/impus.msb
> /opt/oracle/client_libs/rdbms/mesg/impus.msg
> /opt/oracle/client_libs/rdbms/mesg/kgpe.msb
> /opt/oracle/client_libs/rdbms/mesg/kgpus.msb
> /opt/oracle/client_libs/rdbms/mesg/kgpus.msg
> /opt/oracle/client_libs/rdbms/mesg/kope.msb
> /opt/oracle/client_libs/rdbms/mesg/kopus.msb
> /opt/oracle/client_libs/rdbms/mesg/kopus.msg
> /opt/oracle/client_libs/rdbms/mesg/kupe.msb
> /opt/oracle/client_libs/rdbms/mesg/kupus.msb
> /opt/oracle/client_libs/rdbms/mesg/kupus.msg
> /opt/oracle/client_libs/rdbms/mesg/lcde.msb
> /opt/oracle/client_libs/rdbms/mesg/lcdus.msb
> /opt/oracle/client_libs/rdbms/mesg/lcdus.msg
> /opt/oracle/client_libs/rdbms/mesg/mige.msb
> /opt/oracle/client_libs/rdbms/mesg/migus.msb
> /opt/oracle/client_libs/rdbms/mesg/migus.msg
> /opt/oracle/client_libs/rdbms/mesg/nide.msb
> /opt/oracle/client_libs/rdbms/mesg/nidus.msb
> /opt/oracle/client_libs/rdbms/mesg/nidus.msg
> /opt/oracle/client_libs/rdbms/mesg/ocie.msb
> /opt/oracle/client_libs/rdbms/mesg/ocius.msb
> /opt/oracle/client_libs/rdbms/mesg/ocius.msg
> /opt/oracle/client_libs/rdbms/mesg/opwe.msb
> /opt/oracle/client_libs/rdbms/mesg/opwus.msb
> /opt/oracle/client_libs/rdbms/mesg/opwus.msg
> /opt/oracle/client_libs/rdbms/mesg/orae.msb
> /opt/oracle/client_libs/rdbms/mesg/oraus.msb
> /opt/oracle/client_libs/rdbms/mesg/oraus.msg
> /opt/oracle/client_libs/rdbms/mesg/qsme.msb
> /opt/oracle/client_libs/rdbms/mesg/qsmus.msb
> /opt/oracle/client_libs/rdbms/mesg/qsmus.msg
> /opt/oracle/client_libs/rdbms/mesg/rmane.msb
> /opt/oracle/client_libs/rdbms/mesg/rmanus.msb
> /opt/oracle/client_libs/rdbms/mesg/rmanus.msg
> /opt/oracle/client_libs/rdbms/mesg/sbte.msb
> /opt/oracle/client_libs/rdbms/mesg/sbtus.msb
> /opt/oracle/client_libs/rdbms/mesg/sbtus.msg
> /opt/oracle/client_libs/rdbms/mesg/ule.msb
> /opt/oracle/client_libs/rdbms/mesg/ulus.msb
> /opt/oracle/client_libs/rdbms/mesg/ulus.msg
> 
> and export ORACLE_HOME=/opt/oracle/oraclient_libs/
> export LD_LIBRARY_PATH=/opt/oracle/oraclient/libs/lib
> 
> And all seems to work, but If I get a cursor, execute an "INSERT INTO
> publicity ..." query and a "SELECT * FROM publicity", the insert is ok,
> but the select give me a segmentation fault...
> Need I other libraries?
> When I installed the full oracle client all works correctly...
> 
> P.D: I'm using SuSE 8.0.
> 
> Thanks.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

[cx-oracle-users] Segmentation Fault

[Antonio B. M. <ant...@li...>]

Hi all:
I'm developing some python utilities and this utilities need to get/set
information from a Oracle D.B.
I have packed the oracle client libraries in a RPM with this files:

/opt/oracle/client_libs/lib/libclntsh.so.9.0
/opt/oracle/client_libs/lib/libwtc9.so
/opt/oracle/client_libs/network/admin/tnsnames.ora
/opt/oracle/client_libs/oracore/zoneinfo/timezlrg.dat
/opt/oracle/client_libs/oracore/zoneinfo/timezone.dat
/opt/oracle/client_libs/rdbms/mesg/bbede.msb
/opt/oracle/client_libs/rdbms/mesg/bbedus.msb
/opt/oracle/client_libs/rdbms/mesg/bbedus.msg
/opt/oracle/client_libs/rdbms/mesg/dbve.msb
/opt/oracle/client_libs/rdbms/mesg/dbvus.msb
/opt/oracle/client_libs/rdbms/mesg/dbvus.msg
/opt/oracle/client_libs/rdbms/mesg/expe.msb
/opt/oracle/client_libs/rdbms/mesg/expus.msb
/opt/oracle/client_libs/rdbms/mesg/expus.msg
/opt/oracle/client_libs/rdbms/mesg/impe.msb
/opt/oracle/client_libs/rdbms/mesg/impus.msb
/opt/oracle/client_libs/rdbms/mesg/impus.msg
/opt/oracle/client_libs/rdbms/mesg/kgpe.msb
/opt/oracle/client_libs/rdbms/mesg/kgpus.msb
/opt/oracle/client_libs/rdbms/mesg/kgpus.msg
/opt/oracle/client_libs/rdbms/mesg/kope.msb
/opt/oracle/client_libs/rdbms/mesg/kopus.msb
/opt/oracle/client_libs/rdbms/mesg/kopus.msg
/opt/oracle/client_libs/rdbms/mesg/kupe.msb
/opt/oracle/client_libs/rdbms/mesg/kupus.msb
/opt/oracle/client_libs/rdbms/mesg/kupus.msg
/opt/oracle/client_libs/rdbms/mesg/lcde.msb
/opt/oracle/client_libs/rdbms/mesg/lcdus.msb
/opt/oracle/client_libs/rdbms/mesg/lcdus.msg
/opt/oracle/client_libs/rdbms/mesg/mige.msb
/opt/oracle/client_libs/rdbms/mesg/migus.msb
/opt/oracle/client_libs/rdbms/mesg/migus.msg
/opt/oracle/client_libs/rdbms/mesg/nide.msb
/opt/oracle/client_libs/rdbms/mesg/nidus.msb
/opt/oracle/client_libs/rdbms/mesg/nidus.msg
/opt/oracle/client_libs/rdbms/mesg/ocie.msb
/opt/oracle/client_libs/rdbms/mesg/ocius.msb
/opt/oracle/client_libs/rdbms/mesg/ocius.msg
/opt/oracle/client_libs/rdbms/mesg/opwe.msb
/opt/oracle/client_libs/rdbms/mesg/opwus.msb
/opt/oracle/client_libs/rdbms/mesg/opwus.msg
/opt/oracle/client_libs/rdbms/mesg/orae.msb
/opt/oracle/client_libs/rdbms/mesg/oraus.msb
/opt/oracle/client_libs/rdbms/mesg/oraus.msg
/opt/oracle/client_libs/rdbms/mesg/qsme.msb
/opt/oracle/client_libs/rdbms/mesg/qsmus.msb
/opt/oracle/client_libs/rdbms/mesg/qsmus.msg
/opt/oracle/client_libs/rdbms/mesg/rmane.msb
/opt/oracle/client_libs/rdbms/mesg/rmanus.msb
/opt/oracle/client_libs/rdbms/mesg/rmanus.msg
/opt/oracle/client_libs/rdbms/mesg/sbte.msb
/opt/oracle/client_libs/rdbms/mesg/sbtus.msb
/opt/oracle/client_libs/rdbms/mesg/sbtus.msg
/opt/oracle/client_libs/rdbms/mesg/ule.msb
/opt/oracle/client_libs/rdbms/mesg/ulus.msb
/opt/oracle/client_libs/rdbms/mesg/ulus.msg

and export ORACLE_HOME=/opt/oracle/oraclient_libs/
export LD_LIBRARY_PATH=/opt/oracle/oraclient/libs/lib

And all seems to work, but If I get a cursor, execute an "INSERT INTO
publicity ..." query and a "SELECT * FROM publicity", the insert is ok,
but the select give me a segmentation fault...
Need I other libraries?
When I installed the full oracle client all works correctly...

P.D: I'm using SuSE 8.0.

Thanks.
-- 
Antonio Beamud Montero <ant...@li...>

[cx-oracle-users] cx_Oracle 4.0

[Anthony T. <an...@co...>]

What is cx_Oracle?

cx_Oracle is a Python extension module that allows access to Oracle and
conforms to the Python database API 2.0 specifications with a few
exceptions.


Where do I get it?

http://starship.python.net/crew/atuining
http://www.computronix.com/utilities.shtml
(it may be a few days before the second site is updated)


What's new?
 1) Added support for subclassing connections, cursors and session
    pools. The changes involved made it necessary to drop support for
    Python 2.1 and earlier although a branch exists in CVS to allow for
    support of Python 2.1 and earlier if needed.
 2) Connections and session pools can now be created with keyword
    parameters, not just sequential parameters.
 3) Queries now return integers whenever possible and long integers if
    the number will overflow a simple integer. Floats are only returned
    when it is known that the number is a floating point nubmer or the
    integer conversion fails.
 4) Added initial support for user callbacks on OCI functions. See the
    documentation for more details.
 5) Add support for retrieving the bind variable names associated with a
    cursor with a new method bindnames().
 6) Add support for temporary LOB variables. This means that
    setinputsizes() can be used with the values CLOB and BLOB to create
    these temporary LOB variables and allow for the equivalent of
    empty_clob() and empty_blob() since otherwise Oracle will treat
    empty strings as NULL values.
 7) Automatically switch to long strings when the data size exceeds the
    maximum string size that Oracle allows (4000 characters) and raise
    an error if an attempt is made to set a string variable to a size
    that it does not support. This avoids truncation errors as reported
    by Jon Franz.
 8) Add support for global (distributed) transactions and two phase
    commit.
 9) Force the NLS settings for the session so that test tables are
    populated correctly in all circumstances; problems were noted by
    Ralf Braun and Allan Poulsen.
10) Display error messages using the environment handle when the error
    handle has not yet been created; this provides better error messages
    during this rather rare situation.
11) Removed memory leak in callproc() that was reported by Todd
    Whiteman.
12) Make consistent the calls to manipulate memory; otherwise segfaults
    can occur when the pymalloc option is used, as reported by Matt
    Hoskins.
13) Force a rollback when a session is released back to the session
    pool. Apparently the connections are not as stateless as Oracle's
    documentation suggests and this makes the logic consistent with
    normal connections.
14) Removed module method attach(). This can be replaced with a call to
    Connection(handle=) if needed.
 
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

[cx-oracle-users] Procedure for integrating into Zope

[Martinez, M. <MMA...@CS...>]

Hey guys -

Has anyone done a successful integration of cx_Oracle into Zope? If so,
would you please post your procedure?

Thank you -

Regards,
=20
Michael Martinez
ISTM/CSREES
United States Department of Agriculture
---
This email is signed with my digital signature so that you may verify
the authenticity of the sender.

[cx-oracle-users] Procedure for integrating into Zope

[Martinez, M. <MMA...@CS...>]

Guys -

Has anyone done a successful install of cx_Oracle into Zope? If so,
would you please post the procedure?

Regards,
 
Michael Martinez
ISTM/CSREES
United States Department of Agriculture
---
This email is signed with my digital signature so that you may verify
the authenticity of the sender.

Re: [cx-oracle-users] float vs. int

[Geoff G. <ge...@ge...>]

Quoting Anthony Tuininga (an...@co...):
> Just thought I'd let all of you know that I have implemented the
> returning of longs when an integer with more than 9 digits of precision
> is returned. This will be available in the next release of cx_Oracle,
> whenever that is. :-) I have also implemented the ability to subclass
> connections and cursors (requiring Python 2.2 and up) which works quite
> well. Are there any of you out there that are just dying for these
> features? Or is it something that can wait for a month or two?

Sorry about the tardy response. Two weeks ago or more, I would have
begged for immediate access. We go live in production sometime next
week, though, so I think it's too late to switch out the Oracle
package.

I probably won't be able to make real use of the new code until
sometime in January or February, so a Christmas release is just fine.

Thanks!
--G.

-- 
Geoff Gerrietts <geoff @ gerrietts.net> "Many a man's reputation would not 
                                         know his character if they met on 
http://www.gerrietts.net/                the street." --Elbert Hubbard

Re: [cx-oracle-users] float vs. int

[Anthony T. <an...@co...>]

Thanks for the feedback. Currently, the plans for the release are
sometime before Christmas. I'll let you know if those plans change
substantially. I also intend to release these changes as 4.0 and
indicate that Python 2.2 and up is required. I have branched in CVS,
though, so if necessary a Python 2.1 and earlier friendly release can be
made.

On Mon, 2003-11-24 at 15:12, Neil Hodgson wrote:
> Anthony Tuininga:
> 
> > Just thought I'd let all of you know that I have implemented the
> > returning of longs when an integer with more than 9 digits of precision
> > is returned. 
> 
>     Good.
> 
> > I have also implemented the ability to subclass
> > connections and cursors (requiring Python 2.2 and up) which works quite
> > well. 
> 
>     Even better. Currently we have wrappers for connections, cursors, 
> and pools and these would be simpler as subclasses. The wrappers allow 
> easy switching between DCOracle2 and cx_Oracle, which are both good 
> libraries but currently cx_Oracle appears a little better maintained.
> 
> > Are there any of you out there that are just dying for these
> > features? Or is it something that can wait for a month or two?
> 
>     We won't go out of business without them but they would help.
> 
>     Neil
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

Re: [cx-oracle-users] float vs. int

[Neil H. <nho...@eb...>]

Anthony Tuininga:

> Just thought I'd let all of you know that I have implemented the
> returning of longs when an integer with more than 9 digits of precision
> is returned. 

    Good.

> I have also implemented the ability to subclass
> connections and cursors (requiring Python 2.2 and up) which works quite
> well. 

    Even better. Currently we have wrappers for connections, cursors, 
and pools and these would be simpler as subclasses. The wrappers allow 
easy switching between DCOracle2 and cx_Oracle, which are both good 
libraries but currently cx_Oracle appears a little better maintained.

> Are there any of you out there that are just dying for these
> features? Or is it something that can wait for a month or two?

    We won't go out of business without them but they would help.

    Neil

Re: [cx-oracle-users] float vs. int

[Anthony T. <an...@co...>]

Just thought I'd let all of you know that I have implemented the
returning of longs when an integer with more than 9 digits of precision
is returned. This will be available in the next release of cx_Oracle,
whenever that is. :-) I have also implemented the ability to subclass
connections and cursors (requiring Python 2.2 and up) which works quite
well. Are there any of you out there that are just dying for these
features? Or is it something that can wait for a month or two?

On Sat, 2003-09-27 at 21:27, Geoff Gerrietts wrote:
> Quoting Geoff Gerrietts (ge...@ge...):
> > What are the criteria for deciding when a NUMBER will be returned as
> > a float, or when it will be returned as an int or long?
> 
> Terribly sorry; found the answer in the mailing list archives.
> 
> I think for my uses, anything with a scale 0 < sys.maxint should be an
> integer, and anything with a scale 0 > sys.maxint should be a long.
> This does not violate the principle of least surprise, and it also
> relieves me of the burden of post-processing every query result so
> CORBA doesn't barf.
> 
> With decimals, it would be nice to work with fixed point rather than
> floats, but that would likely be a substantial change in my
> application: floats are everywhere, and in several places, I expect
> them to be floats.
> 
> Thanks,
> --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

Re: [cx-oracle-users] import of cx_Oracle fails

[Anthony T. <an...@co...>]

I suspect you are using an older version of the Oracle 9i client, right?
Specifically, you are __NOT__ using Oracle 9.2, right? Older versions of
Oracle 9i do not have support for session pooling which is what the
error message is about. If you can't use Oracle 9.2, I would suggest
installing and using the Oracle 8i version of cx_Oracle instead or
rebuilding cx_Oracle.pyd yourself so that the offending procedure is not
linked. Let me know if this does not solve the problem for you. Thanks.

On Wed, 2003-10-08 at 08:40, Ralf Braun wrote:
> Hello,
> 
> i've installed the latest binary distributions (Python 2.3 and
> cx_Oracle-3.1-win32-9i-py23.exe) under W2k SP4.
> The cx_Oracle-installation was ok (as you can see in the
> cx_Oracle-wininst.log), the file "cx_Oracle.pyd" is on my Python path.
> 
> If I try to use the module, I'll get:
> 
> >>> import cx_Oracle
> 
> Traceback (most recent call last):
>   File "<pyshell#6>", line 1, in -toplevel-
>     import cx_Oracle
> ImportError: DLL load failed: The specified procedure could not be
> found.
> 
> 
> The "oci.dll" is on my search path.
> I'll get the connection with an external call:
>     os.execlp('sqlplus', 'sqlplus', 'system/system@bercsu1')
> 
> SQL*Plus: Release 9.0.1.3.0 - Production on Mi Okt 8 16:25:30 2003
> (c) Copyright 2001 Oracle Corporation.  All rights reserved.
> 
> Verbunden mit: (connected with:)
> Oracle9i Enterprise Edition Release 9.2.0.2.0 - Production
> With the Partitioning, OLAP and Oracle Data Mining options
> JServer Release 9.2.0.2.0 - Production
> SQL> ...
> 
> Are there any hints for diagnostics?
> 
> Regards Ralf
> 
> 
> 
> ______________________________________________________________________
> *** Installation started 2003/10/08 15:12 ***
> Source: C:\TEMP\Transfer\cx_Oracle-3.1-win32-9i-py23.exe
> 020 Reg DB Key: [Software\Microsoft\Windows\CurrentVersion\Uninstall]cx_Oracle-py2.3
> 040 Reg DB Value: [Software\Microsoft\Windows\CurrentVersion\Uninstall\cx_Oracle-py2.3]DisplayName=Python 2.3 cx_Oracle-3.1
> 040 Reg DB Value: [Software\Microsoft\Windows\CurrentVersion\Uninstall\cx_Oracle-py2.3]UninstallString="C:\Local\Programs\Python23\Removecx_Oracle.exe" -u "C:\Local\Programs\Python23\cx_Oracle-wininst.log"
> 100 Made Dir: C:\Local\Programs\Python23\cx_Oracle-doc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\HISTORY.txt
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\LICENSE.TXT
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\README.TXT
> 100 Made Dir: C:\Local\Programs\Python23\cx_Oracle-doc\html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\about.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\blank.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\connobj.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\contents.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\contents.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\cursorobj.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\cx_Oracle.css
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\cx_Oracle.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\dateobj.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\front.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\index.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\index.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\lobobj.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\module.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\modules.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\next.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\node12.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\node4.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\node5.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\previous.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\pyfav.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\sesspool.html
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\up.gif
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\html\varobj.html
> 100 Made Dir: C:\Local\Programs\Python23\cx_Oracle-doc\test
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\Connection.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\Cursor.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\CursorVar.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\DateTimeVar.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\LobVar.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\LongVar.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\NumberVar.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\SessionPool.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\SetupTest.sql
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\SetupTest_9i.sql
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\StringVar.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\test.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\TestEnv.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\test_dbapi20.py
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\TimestampVar.py
> 200 File Copy: C:\Local\Programs\Python23\Lib\site-packages\cx_Oracle.pyd
> 100 Made Dir: C:\Local\Programs\Python23\Lib\site-packages\Release
> 200 File Copy: C:\Local\Programs\Python23\Lib\site-packages\Release\cx_Oracle.def
> 200 File Copy: C:\Local\Programs\Python23\Lib\site-packages\Release\cx_oracle.o
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\TimestampVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\test_dbapi20.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\TestEnv.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\test.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\StringVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\SessionPool.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\NumberVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\LongVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\LobVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\DateTimeVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\CursorVar.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\Cursor.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\Connection.pyc
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\TimestampVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\test_dbapi20.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\TestEnv.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\test.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\StringVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\SessionPool.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\NumberVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\LongVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\LobVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\DateTimeVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\CursorVar.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\Cursor.pyo
> 200 File Copy: C:\Local\Programs\Python23\cx_Oracle-doc\test\Connection.pyo
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

[cx-oracle-users] import of cx_Oracle fails

[Ralf B. <ral...@or...>]

KioqIEluc3RhbGxhdGlvbiBzdGFydGVkIDIwMDMvMTAvMDggMTU6MTIgKioqDQpTb3VyY2U6
IEM6XFRFTVBcVHJhbnNmZXJcY3hfT3JhY2xlLTMuMS13aW4zMi05aS1weTIzLmV4ZQ0KMDIw
IFJlZyBEQiBLZXk6IFtTb2Z0d2FyZVxNaWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lv
blxVbmluc3RhbGxdY3hfT3JhY2xlLXB5Mi4zDQowNDAgUmVnIERCIFZhbHVlOiBbU29mdHdh
cmVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25cVW5pbnN0YWxsXGN4X09yYWNs
ZS1weTIuM11EaXNwbGF5TmFtZT1QeXRob24gMi4zIGN4X09yYWNsZS0zLjENCjA0MCBSZWcg
REIgVmFsdWU6IFtTb2Z0d2FyZVxNaWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxV
bmluc3RhbGxcY3hfT3JhY2xlLXB5Mi4zXVVuaW5zdGFsbFN0cmluZz0iQzpcTG9jYWxcUHJv
Z3JhbXNcUHl0aG9uMjNcUmVtb3ZlY3hfT3JhY2xlLmV4ZSIgLXUgIkM6XExvY2FsXFByb2dy
YW1zXFB5dGhvbjIzXGN4X09yYWNsZS13aW5pbnN0LmxvZyINCjEwMCBNYWRlIERpcjogQzpc
TG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvYw0KMjAwIEZpbGUgQ29weTog
QzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1xISVNUT1JZLnR4dA0K
MjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRv
Y1xMSUNFTlNFLlRYVA0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9u
MjNcY3hfT3JhY2xlLWRvY1xSRUFETUUuVFhUDQoxMDAgTWFkZSBEaXI6IEM6XExvY2FsXFBy
b2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcaHRtbA0KMjAwIEZpbGUgQ29weTogQzpc
TG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1xodG1sXGFib3V0Lmh0bWwN
CjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1k
b2NcaHRtbFxibGFuay5naWYNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5
dGhvbjIzXGN4X09yYWNsZS1kb2NcaHRtbFxjb25ub2JqLmh0bWwNCjIwMCBGaWxlIENvcHk6
IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcaHRtbFxjb250ZW50
cy5naWYNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09y
YWNsZS1kb2NcaHRtbFxjb250ZW50cy5odG1sDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQ
cm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxcY3Vyc29yb2JqLmh0bWwNCjIw
MCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2Nc
aHRtbFxjeF9PcmFjbGUuY3NzDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQ
eXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxcY3hfT3JhY2xlLmh0bWwNCjIwMCBGaWxlIENv
cHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcaHRtbFxkYXRl
b2JqLmh0bWwNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4
X09yYWNsZS1kb2NcaHRtbFxmcm9udC5odG1sDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQ
cm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxcaW5kZXguZ2lmDQoyMDAgRmls
ZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxc
aW5kZXguaHRtbA0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNc
Y3hfT3JhY2xlLWRvY1xodG1sXGxvYm9iai5odG1sDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2Nh
bFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxcbW9kdWxlLmh0bWwNCjIw
MCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2Nc
aHRtbFxtb2R1bGVzLmdpZg0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0
aG9uMjNcY3hfT3JhY2xlLWRvY1xodG1sXG5leHQuZ2lmDQoyMDAgRmlsZSBDb3B5OiBDOlxM
b2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxcbm9kZTEyLmh0bWwN
CjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1k
b2NcaHRtbFxub2RlNC5odG1sDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQ
eXRob24yM1xjeF9PcmFjbGUtZG9jXGh0bWxcbm9kZTUuaHRtbA0KMjAwIEZpbGUgQ29weTog
QzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1xodG1sXHByZXZpb3Vz
LmdpZg0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3Jh
Y2xlLWRvY1xodG1sXHB5ZmF2LmdpZg0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3Jh
bXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1xodG1sXHNlc3Nwb29sLmh0bWwNCjIwMCBGaWxl
IENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcaHRtbFx1
cC5naWYNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09y
YWNsZS1kb2NcaHRtbFx2YXJvYmouaHRtbA0KMTAwIE1hZGUgRGlyOiBDOlxMb2NhbFxQcm9n
cmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3QNCjIwMCBGaWxlIENvcHk6IEM6XExv
Y2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxDb25uZWN0aW9uLnB5
DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUt
ZG9jXHRlc3RcQ3Vyc29yLnB5DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQ
eXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3RcQ3Vyc29yVmFyLnB5DQoyMDAgRmlsZSBDb3B5
OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3RcRGF0ZVRp
bWVWYXIucHkNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4
X09yYWNsZS1kb2NcdGVzdFxMb2JWYXIucHkNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFBy
b2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxMb25nVmFyLnB5DQoyMDAgRmls
ZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3Rc
TnVtYmVyVmFyLnB5DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24y
M1xjeF9PcmFjbGUtZG9jXHRlc3RcU2Vzc2lvblBvb2wucHkNCjIwMCBGaWxlIENvcHk6IEM6
XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxTZXR1cFRlc3Qu
c3FsDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFj
bGUtZG9jXHRlc3RcU2V0dXBUZXN0XzlpLnNxbA0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxc
UHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1x0ZXN0XFN0cmluZ1Zhci5weQ0KMjAw
IEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1x0
ZXN0XHRlc3QucHkNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIz
XGN4X09yYWNsZS1kb2NcdGVzdFxUZXN0RW52LnB5DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2Nh
bFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3RcdGVzdF9kYmFwaTIwLnB5
DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUt
ZG9jXHRlc3RcVGltZXN0YW1wVmFyLnB5DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9n
cmFtc1xQeXRob24yM1xMaWJcc2l0ZS1wYWNrYWdlc1xjeF9PcmFjbGUucHlkDQoxMDAgTWFk
ZSBEaXI6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXExpYlxzaXRlLXBhY2thZ2VzXFJl
bGVhc2UNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXExpYlxz
aXRlLXBhY2thZ2VzXFJlbGVhc2VcY3hfT3JhY2xlLmRlZg0KMjAwIEZpbGUgQ29weTogQzpc
TG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcTGliXHNpdGUtcGFja2FnZXNcUmVsZWFzZVxjeF9v
cmFjbGUubw0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hf
T3JhY2xlLWRvY1x0ZXN0XFRpbWVzdGFtcFZhci5weWMNCjIwMCBGaWxlIENvcHk6IEM6XExv
Y2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFx0ZXN0X2RiYXBpMjAu
cHljDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFj
bGUtZG9jXHRlc3RcVGVzdEVudi5weWMNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dy
YW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFx0ZXN0LnB5Yw0KMjAwIEZpbGUgQ29w
eTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1x0ZXN0XFN0cmlu
Z1Zhci5weWMNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4
X09yYWNsZS1kb2NcdGVzdFxTZXNzaW9uUG9vbC5weWMNCjIwMCBGaWxlIENvcHk6IEM6XExv
Y2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxOdW1iZXJWYXIucHlj
DQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUt
ZG9jXHRlc3RcTG9uZ1Zhci5weWMNCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1z
XFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxMb2JWYXIucHljDQoyMDAgRmlsZSBDb3B5
OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3RcRGF0ZVRp
bWVWYXIucHljDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xj
eF9PcmFjbGUtZG9jXHRlc3RcQ3Vyc29yVmFyLnB5Yw0KMjAwIEZpbGUgQ29weTogQzpcTG9j
YWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1x0ZXN0XEN1cnNvci5weWMNCjIw
MCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2Nc
dGVzdFxDb25uZWN0aW9uLnB5Yw0KMjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNc
UHl0aG9uMjNcY3hfT3JhY2xlLWRvY1x0ZXN0XFRpbWVzdGFtcFZhci5weW8NCjIwMCBGaWxl
IENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFx0
ZXN0X2RiYXBpMjAucHlvDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRo
b24yM1xjeF9PcmFjbGUtZG9jXHRlc3RcVGVzdEVudi5weW8NCjIwMCBGaWxlIENvcHk6IEM6
XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFx0ZXN0LnB5bw0K
MjAwIEZpbGUgQ29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRv
Y1x0ZXN0XFN0cmluZ1Zhci5weW8NCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1z
XFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxTZXNzaW9uUG9vbC5weW8NCjIwMCBGaWxl
IENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxO
dW1iZXJWYXIucHlvDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24y
M1xjeF9PcmFjbGUtZG9jXHRlc3RcTG9uZ1Zhci5weW8NCjIwMCBGaWxlIENvcHk6IEM6XExv
Y2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4X09yYWNsZS1kb2NcdGVzdFxMb2JWYXIucHlvDQoy
MDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFtc1xQeXRob24yM1xjeF9PcmFjbGUtZG9j
XHRlc3RcRGF0ZVRpbWVWYXIucHlvDQoyMDAgRmlsZSBDb3B5OiBDOlxMb2NhbFxQcm9ncmFt
c1xQeXRob24yM1xjeF9PcmFjbGUtZG9jXHRlc3RcQ3Vyc29yVmFyLnB5bw0KMjAwIEZpbGUg
Q29weTogQzpcTG9jYWxcUHJvZ3JhbXNcUHl0aG9uMjNcY3hfT3JhY2xlLWRvY1x0ZXN0XEN1
cnNvci5weW8NCjIwMCBGaWxlIENvcHk6IEM6XExvY2FsXFByb2dyYW1zXFB5dGhvbjIzXGN4
X09yYWNsZS1kb2NcdGVzdFxDb25uZWN0aW9uLnB5bw0K

Re: [SPAM-bayes] Re: [cx-oracle-users] float vs. int

[Anthony T. <an...@co...>]

On Mon, 2003-10-06 at 14:40, Geoff Gerrietts wrote:
> Quoting Anthony Tuininga (an...@co...):
> > > For columns with a precision > 9 and a scale 0, DCOracle2 returns a
> > > Long by default, without comparing the actual value to sys.maxint.
> > > DCOracle compares the actual value and returns a Long only if an Int
> > > would overflow.
> > 
> > Hmm. Python 2.3 will automatically convert to long when the value won't
> > fit inside an integer. Python 2.2 and below will not, of course, but
> > that could be checked by looking for an OverflowError and doing the
> > right conversion otherwise. I think that makes a lot of sense. What do
> > you think?
> 
> Yes, that goes along with what I think the principle of least surprise
> should dictate. The full unification in 2.3 is obviously the best of
> all worlds, but until everyone's on 2.3+, getting as close as possible
> seems like the "right" thing to do (and it has the advantage of
> continuing to be the right thing in 2.3 and beyond).

Sounds good. If no one else objects, I'll implement that in the next
release.

> > > DCOracle does all its data conversion by poking around inside Oracle's
> > > data structures, I think. I don't know the OCI API very well but very
> > > few OCI calls are actually being made by DCOracle.
> > 
> > I believe I am making the same ones. I didn't actually look but Oracle
> > does provide the scale and precision of numbers and that is what I am
> > checking.
> 
> The original DCOracle started life as a SWIG wrap of the OCI API. It
> was heavily hacked to produce a more-or-less compliant module.
> 
> As near I can tell -- which is not too close, because I've spent only
> a couple of days spread over a couple of years looking at the
> Byzantine beast -- it copies data directly out of the OCI's mapped
> memory region and into some Pythonic data structures. Chances are good
> to middling that I am missing something key, but doing a grep for
> fairly standard calls (like "OCINumber.*") yields hits only in object
> files.
> 
> DCOracle2 I am even less familiar with. It does use the more regular
> calls, though.

I took a quick peek at the current code in DCOracle2. Apparently they
don't use the OCINumber routines at all although they are found (with a
grep) inside the binaries that they ship, which is rather strange.
Instead, they parse the actual 22-byte value that is returned by Oracle
and look at the precision and scale stored in that value. I have no
intentions of going down that road! :-)

> > Floating point is always a problem in that regard. Thus the introduction
> > of fixed point classes. But they have their own set of problems --
> > mostly that they are not intrinsic to a lot of other algorithms. Someone
> > earlier posted a link to a fixed point class. I may do something a
> > little less functional directly in C or provide a mechanism for
> > registering a "fixed point" class for use by cx_Oracle in returning such
> > things. Any thoughts on that?
> 
> Floating point is pretty standard. Fixed point really isn't, though. I
> mean, there's the "standard" module Tim Peters wrote. I think I read
> once upon a time that Aahz was looking at tightening that up possibly
> for inclusion in the standard library but I honestly haven't followed
> it.
> 
> I do know that the CORBA IDL mapping to Python includes some kind of
> hijinx surrounding fixed point, too. To me, that looks like an
> opportunity for an implementation to "go rogue" and not conform to the
> standards. Integration with the DB layer seems like another one.
> 
> I'm not sure what the /right/ answer is to all the fixed point and
> floating point issues. I'm certainly not well-versed in the array of
> possible solutions, because to date I've been ducking my head and
> gambling that a float will be good enough. But I think any solution's
> value will be measured in part by how easy it is to use with other
> fixed point / floating point solutions, with "effortless" or
> "identical" being the ideal.
> 
> I think that's just a wordy way of saying "standards are good." :)

Up to this point I have used floating point where I know it will work
and otherwise I have used strings. That works but it does leave a bad
taste in one's mouth if one is expecting a more "transparent" solution.
I'll give this a little more thought before I do anything drastic,
though. If you (or anyone else) has any other ideas, please fire them
this way.

> Thanks,
> --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

Re: [SPAM-bayes] Re: [cx-oracle-users] float vs. int

[Geoff G. <ge...@ge...>]

Quoting Anthony Tuininga (an...@co...):
> > For columns with a precision > 9 and a scale 0, DCOracle2 returns a
> > Long by default, without comparing the actual value to sys.maxint.
> > DCOracle compares the actual value and returns a Long only if an Int
> > would overflow.
> 
> Hmm. Python 2.3 will automatically convert to long when the value won't
> fit inside an integer. Python 2.2 and below will not, of course, but
> that could be checked by looking for an OverflowError and doing the
> right conversion otherwise. I think that makes a lot of sense. What do
> you think?

Yes, that goes along with what I think the principle of least surprise
should dictate. The full unification in 2.3 is obviously the best of
all worlds, but until everyone's on 2.3+, getting as close as possible
seems like the "right" thing to do (and it has the advantage of
continuing to be the right thing in 2.3 and beyond).

> > DCOracle does all its data conversion by poking around inside Oracle's
> > data structures, I think. I don't know the OCI API very well but very
> > few OCI calls are actually being made by DCOracle.
> 
> I believe I am making the same ones. I didn't actually look but Oracle
> does provide the scale and precision of numbers and that is what I am
> checking.

The original DCOracle started life as a SWIG wrap of the OCI API. It
was heavily hacked to produce a more-or-less compliant module.

As near I can tell -- which is not too close, because I've spent only
a couple of days spread over a couple of years looking at the
Byzantine beast -- it copies data directly out of the OCI's mapped
memory region and into some Pythonic data structures. Chances are good
to middling that I am missing something key, but doing a grep for
fairly standard calls (like "OCINumber.*") yields hits only in object
files.

DCOracle2 I am even less familiar with. It does use the more regular
calls, though.

> Floating point is always a problem in that regard. Thus the introduction
> of fixed point classes. But they have their own set of problems --
> mostly that they are not intrinsic to a lot of other algorithms. Someone
> earlier posted a link to a fixed point class. I may do something a
> little less functional directly in C or provide a mechanism for
> registering a "fixed point" class for use by cx_Oracle in returning such
> things. Any thoughts on that?

Floating point is pretty standard. Fixed point really isn't, though. I
mean, there's the "standard" module Tim Peters wrote. I think I read
once upon a time that Aahz was looking at tightening that up possibly
for inclusion in the standard library but I honestly haven't followed
it.

I do know that the CORBA IDL mapping to Python includes some kind of
hijinx surrounding fixed point, too. To me, that looks like an
opportunity for an implementation to "go rogue" and not conform to the
standards. Integration with the DB layer seems like another one.

I'm not sure what the /right/ answer is to all the fixed point and
floating point issues. I'm certainly not well-versed in the array of
possible solutions, because to date I've been ducking my head and
gambling that a float will be good enough. But I think any solution's
value will be measured in part by how easy it is to use with other
fixed point / floating point solutions, with "effortless" or
"identical" being the ideal.

I think that's just a wordy way of saying "standards are good." :)

Thanks,
--G.

-- 
Geoff Gerrietts             "Me and my homies, we tag O.D.."
<geoff at gerrietts net>        --Unknown grafitti artist at a party

Re: [SPAM-bayes] Re: [cx-oracle-users] float vs. int

[Anthony T. <an...@co...>]

On Mon, 2003-10-06 at 13:17, Geoff Gerrietts wrote:
> Quoting Anthony Tuininga (an...@co...):
> > The only possibility that I can think of right now is that they incur
> > the overhead of checking if trunc(result) == result and returning an
> > integer as a result. That has two problems with it, though. (1) the
> > performance penalty and (2) the possibility of getting back an integer
> > when you wanted a float
> 
> DCOracle and DCOracle2 both returns a float in this (select count(*))
> case.

Ok. So someone else had the same problem and came up with the same
solution. Good. :-)

> For columns with a precision > 9 and a scale 0, DCOracle2 returns a
> Long by default, without comparing the actual value to sys.maxint.
> DCOracle compares the actual value and returns a Long only if an Int
> would overflow.

Hmm. Python 2.3 will automatically convert to long when the value won't
fit inside an integer. Python 2.2 and below will not, of course, but
that could be checked by looking for an OverflowError and doing the
right conversion otherwise. I think that makes a lot of sense. What do
you think?

> DCOracle does all its data conversion by poking around inside Oracle's
> data structures, I think. I don't know the OCI API very well but very
> few OCI calls are actually being made by DCOracle.

I believe I am making the same ones. I didn't actually look but Oracle
does provide the scale and precision of numbers and that is what I am
checking.

> DCOracle2 seems to use slightly more of the OCI API, but the code is
> nowhere near as clean and comprehensible as the code in cx_Oracle.

Thanks. It would be interesting to note which parts of the OCI API
DCOracle uses that cx_Oracle does not -- mostly out of curiosity but
sometimes interesting enhancements turn up as a result... :-)

> I prefer the DCOracle behavior only because I have coded to it in the
> past. I think the DCOracle behavior makes reasonable sense, but the
> DCOracle2 behavior does, too. Of course, I've already voted... ;)

See the above. Does that make sense to you?

> I don't deal with a lot of large numeric values, but I am a little
> concerned about FP "roundoff" and FP precision errors, and returning
> all values as strings is interesting but incurs more overhead than I'm
> willing to stomach.

Floating point is always a problem in that regard. Thus the introduction
of fixed point classes. But they have their own set of problems --
mostly that they are not intrinsic to a lot of other algorithms. Someone
earlier posted a link to a fixed point class. I may do something a
little less functional directly in C or provide a mechanism for
registering a "fixed point" class for use by cx_Oracle in returning such
things. Any thoughts on that?

> Just hoping to add some points of comparison to the discussion.

Thanks.

> Thanks,
> --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

Re: [SPAM-bayes] Re: [cx-oracle-users] float vs. int

[Geoff G. <ge...@ge...>]

Quoting Anthony Tuininga (an...@co...):
> The only possibility that I can think of right now is that they incur
> the overhead of checking if trunc(result) == result and returning an
> integer as a result. That has two problems with it, though. (1) the
> performance penalty and (2) the possibility of getting back an integer
> when you wanted a float

DCOracle and DCOracle2 both returns a float in this (select count(*))
case.

For columns with a precision > 9 and a scale 0, DCOracle2 returns a
Long by default, without comparing the actual value to sys.maxint.
DCOracle compares the actual value and returns a Long only if an Int
would overflow.

DCOracle does all its data conversion by poking around inside Oracle's
data structures, I think. I don't know the OCI API very well but very
few OCI calls are actually being made by DCOracle.

DCOracle2 seems to use slightly more of the OCI API, but the code is
nowhere near as clean and comprehensible as the code in cx_Oracle.

I prefer the DCOracle behavior only because I have coded to it in the
past. I think the DCOracle behavior makes reasonable sense, but the
DCOracle2 behavior does, too. Of course, I've already voted... ;)

I don't deal with a lot of large numeric values, but I am a little
concerned about FP "roundoff" and FP precision errors, and returning
all values as strings is interesting but incurs more overhead than I'm
willing to stomach.

Just hoping to add some points of comparison to the discussion.

Thanks,
--G.

-- 
Geoff Gerrietts             "Whenever people agree with me I always 
<geoff at gerrietts net>     feel I must be wrong." --Oscar Wilde

Re: [SPAM-bayes] Re: [cx-oracle-users] float vs. int

[Anthony T. <an...@co...>]

The only possibility that I can think of right now is that they incur
the overhead of checking if trunc(result) == result and returning an
integer as a result. That has two problems with it, though. (1) the
performance penalty and (2) the possibility of getting back an integer
when you wanted a float

On Mon, 2003-10-06 at 12:25, Marcos Sánchez Provencio wrote:
> But other interfaces do return the right thing, ¿don't they? I mean,
> odbc and SQL*Plus. (Can't check right now though)
> 
> El lun, 06-10-2003 a las 19:17, Anthony Tuininga escribió:
> > On Sat, 2003-09-27 at 21:27, Geoff Gerrietts wrote:
> > > Quoting Geoff Gerrietts (ge...@ge...):
> > > > What are the criteria for deciding when a NUMBER will be returned as
> > > > a float, or when it will be returned as an int or long?
> > > 
> > > Terribly sorry; found the answer in the mailing list archives.
> > 
> > No problem. This isn't the first time the problem has appeared. It is
> > one of those things that annoys me every time I think about it. But I
> > haven't found a really useful solution so far.
> > 
> > > I think for my uses, anything with a scale 0 < sys.maxint should be an
> > > integer, and anything with a scale 0 > sys.maxint should be a long.
> > > This does not violate the principle of least surprise, and it also
> > > relieves me of the burden of post-processing every query result so
> > > CORBA doesn't barf.
> > 
> > That should be quite reasonable and simple to implement. I am assuming
> > that you mean "value" when you state "scale" above, right? Does anyone
> > have any objections to that implementation? Of course, it doesn't solve
> > the problem that most people immediately complain about, which is "Why
> > do I get a float back when I issue the query 'select count(*) from
> > table'"? Unfortunately, Oracle returns a scale of "0" and a precision of
> > "0" meaning no information is available as to whether an integer or a
> > floating point number is being returned.
> > 
> > > With decimals, it would be nice to work with fixed point rather than
> > > floats, but that would likely be a substantial change in my
> > > application: floats are everywhere, and in several places, I expect
> > > them to be floats.
> > 
> > True. I've considered adding an extension which would allow
> > specification of what is to be returned. I still haven't come up with a
> > reasonable name for it or whether I should overload setoutputsize() in
> > some way. Essentially, it would mean the following:
> > 
> > cursor.somefunc(1, cx_Oracle.INTEGER)
> > cursor.somefunc(2, cx_Oracle.FLOAT)
> > cursor.somefunc(3, cx_Oracle.FIXED_POINT)
> > 
> > where of course, the constants defined above don't exist yet and
> > "somefunc" needs to be named properly so that it makes sense. Any
> > suggestions?
> > 
> > > Thanks,
> > > --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

Re: [cx-oracle-users] float vs. int

[Marcos P. <msa...@gr...>]

But other interfaces do return the right thing, =BFdon't they? I mean,
odbc and SQL*Plus. (Can't check right now though)

El lun, 06-10-2003 a las 19:17, Anthony Tuininga escribi=F3:
> On Sat, 2003-09-27 at 21:27, Geoff Gerrietts wrote:
> > Quoting Geoff Gerrietts (ge...@ge...):
> > > What are the criteria for deciding when a NUMBER will be returned as
> > > a float, or when it will be returned as an int or long?
> >=20
> > Terribly sorry; found the answer in the mailing list archives.
>=20
> No problem. This isn't the first time the problem has appeared. It is
> one of those things that annoys me every time I think about it. But I
> haven't found a really useful solution so far.
>=20
> > I think for my uses, anything with a scale 0 < sys.maxint should be an
> > integer, and anything with a scale 0 > sys.maxint should be a long.
> > This does not violate the principle of least surprise, and it also
> > relieves me of the burden of post-processing every query result so
> > CORBA doesn't barf.
>=20
> That should be quite reasonable and simple to implement. I am assuming
> that you mean "value" when you state "scale" above, right? Does anyone
> have any objections to that implementation? Of course, it doesn't solve
> the problem that most people immediately complain about, which is "Why
> do I get a float back when I issue the query 'select count(*) from
> table'"? Unfortunately, Oracle returns a scale of "0" and a precision of
> "0" meaning no information is available as to whether an integer or a
> floating point number is being returned.
>=20
> > With decimals, it would be nice to work with fixed point rather than
> > floats, but that would likely be a substantial change in my
> > application: floats are everywhere, and in several places, I expect
> > them to be floats.
>=20
> True. I've considered adding an extension which would allow
> specification of what is to be returned. I still haven't come up with a
> reasonable name for it or whether I should overload setoutputsize() in
> some way. Essentially, it would mean the following:
>=20
> cursor.somefunc(1, cx_Oracle.INTEGER)
> cursor.somefunc(2, cx_Oracle.FLOAT)
> cursor.somefunc(3, cx_Oracle.FIXED_POINT)
>=20
> where of course, the constants defined above don't exist yet and
> "somefunc" needs to be named properly so that it makes sense. Any
> suggestions?
>=20
> > Thanks,
> > --G.
--=20
Marcos S=E1nchez Provencio <msa...@gr...>
www.burke.es

Re: [cx-oracle-users] float vs. int

[Anthony T. <an...@co...>]

On Sat, 2003-09-27 at 21:27, Geoff Gerrietts wrote:
> Quoting Geoff Gerrietts (ge...@ge...):
> > What are the criteria for deciding when a NUMBER will be returned as
> > a float, or when it will be returned as an int or long?
> 
> Terribly sorry; found the answer in the mailing list archives.

No problem. This isn't the first time the problem has appeared. It is
one of those things that annoys me every time I think about it. But I
haven't found a really useful solution so far.

> I think for my uses, anything with a scale 0 < sys.maxint should be an
> integer, and anything with a scale 0 > sys.maxint should be a long.
> This does not violate the principle of least surprise, and it also
> relieves me of the burden of post-processing every query result so
> CORBA doesn't barf.

That should be quite reasonable and simple to implement. I am assuming
that you mean "value" when you state "scale" above, right? Does anyone
have any objections to that implementation? Of course, it doesn't solve
the problem that most people immediately complain about, which is "Why
do I get a float back when I issue the query 'select count(*) from
table'"? Unfortunately, Oracle returns a scale of "0" and a precision of
"0" meaning no information is available as to whether an integer or a
floating point number is being returned.

> With decimals, it would be nice to work with fixed point rather than
> floats, but that would likely be a substantial change in my
> application: floats are everywhere, and in several places, I expect
> them to be floats.

True. I've considered adding an extension which would allow
specification of what is to be returned. I still haven't come up with a
reasonable name for it or whether I should overload setoutputsize() in
some way. Essentially, it would mean the following:

cursor.somefunc(1, cx_Oracle.INTEGER)
cursor.somefunc(2, cx_Oracle.FLOAT)
cursor.somefunc(3, cx_Oracle.FIXED_POINT)

where of course, the constants defined above don't exist yet and
"somefunc" needs to be named properly so that it makes sense. Any
suggestions?

> Thanks,
> --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

Re: [cx-oracle-users] float vs. int

[Geoff G. <ge...@ge...>]

Quoting Geoff Gerrietts (ge...@ge...):
> What are the criteria for deciding when a NUMBER will be returned as
> a float, or when it will be returned as an int or long?

Terribly sorry; found the answer in the mailing list archives.

I think for my uses, anything with a scale 0 < sys.maxint should be an
integer, and anything with a scale 0 > sys.maxint should be a long.
This does not violate the principle of least surprise, and it also
relieves me of the burden of post-processing every query result so
CORBA doesn't barf.

With decimals, it would be nice to work with fixed point rather than
floats, but that would likely be a substantial change in my
application: floats are everywhere, and in several places, I expect
them to be floats.

Thanks,
--G.

-- 
Geoff Gerrietts                        "Evolution takes no prisoners."
<ge...@ge...>                                       -- Mandy

[cx-oracle-users] float vs. int

[Geoff G. <ge...@ge...>]

What are the criteria for deciding when a NUMBER will be returned as a
float, or when it will be returned as an int or long?

Thanks,
--G.

-- 
Geoff Gerrietts <geoff at gerrietts dot net>
-rw-rw-rw-:         permissions of the beast

Re: [cx-oracle-users] How to insert LOB/CLOB/BLOB ??

[Anthony T. <an...@co...>]

The code you give works fine on our machines which have the same
configuration except for Oracle, which is Oracle 8.1.7 and Oracle 9.2.0.
There are a fair number of bugs in Oracle 8.1.5 and I would recommend
upgrading Oracle to at least 8.1.7, if not 9.2.0 (depending on your
needs and the risks you see with either upgrade). Oracle is terminating
support for Oracle 8i at the end of the year and Oracle 10g is coming
out at the end of this week.

If upgrading is not an option for some reason, you will have to write
your code differently to work around the bugs in Oracle 8.1.5. You can
try this style of code as well:

import cx_Oracle

connection = cx_Oracle.connect("user/pw@dsn")
cursor = connection.cursor()
cursor.execute("insert into testclob values (:pint, empty_clob())",
        pint = 1)
cursor.execute("select clobval from testclob where id = :pint",
        pint = 1)
clob, = cursor.fetchone()
clob.write(longString)

This method is more code and more network traffic intensive but
otherwise works identically.

Hope this helps.

On Wed, 2003-09-03 at 06:39, vi...@cs... wrote:
> Hi all,
>   I am new to this list and also to the cx_Oracle package. Previously I was 
> working with other database systems with Python. I recently switched to
> Oracle and cx_Oracle. 
>   Now I am learning to use this package using the tests provided with package.
> But I am facing problems in inserting large object data in tables. 
> I have a table as : clob(id integer PK,clobval clob NN)
> Now I try to insert some data in it:
>   >>longString="abcd"*2500
>   >>cur=con.cursor()
>   >>cur.setinputsizes(pstr=cx_Oracle.LONG_STRING)
>   >>cur.execute("insert into testclob values(:pint,:pstr)",pint=1,pstr=longString)
> 
> But here I gets error:
>   cx_Oracle.DatabaseError: ORA-01461: can bind a LONG value only for insert into a LONG column
> 
> Please Help..
> 
> I am using Python 2.3/cx_Oracle 3.1/ Oracle 8.1.5 on Windows 2k (SP4).
> 
> TIA and Kind Regards,
> Vivek Kumar
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com

[cx-oracle-users] How to insert LOB/CLOB/BLOB ??

[<vi...@cs...>]

Hi all,
  I am new to this list and also to the cx_Oracle package. Previously I was 
working with other database systems with Python. I recently switched to
Oracle and cx_Oracle. 
  Now I am learning to use this package using the tests provided with package.
But I am facing problems in inserting large object data in tables. 
I have a table as : clob(id integer PK,clobval clob NN)
Now I try to insert some data in it:
  >>longString="abcd"*2500
  >>cur=con.cursor()
  >>cur.setinputsizes(pstr=cx_Oracle.LONG_STRING)
  >>cur.execute("insert into testclob values(:pint,:pstr)",pint=1,pstr=longString)

But here I gets error:
  cx_Oracle.DatabaseError: ORA-01461: can bind a LONG value only for insert into a LONG column

Please Help..

I am using Python 2.3/cx_Oracle 3.1/ Oracle 8.1.5 on Windows 2k (SP4).

TIA and Kind Regards,
Vivek Kumar

Re: [cx-oracle-users] Re: cx_Oracle Python utility

[Geoff G. <ge...@ge...>]

Quoting Anthony Tuininga (an...@co...):
> Its not a "feature" but rather a result of the fact that I only actually
> use Python 2.2 and Python 2.3 now. I have no problem with a patch of
> that nature. Have you run the test suite after building with that patch?
> And does it pass completely (other than the Python 2.2 specific stuff)?

Ah, would that I could be in your situation.

I have not run the test suite. When I just tried (python test.py) to
run it under the unpatched version, I got an error:

  Traceback (most recent call last):
    File "test.py", line 42, in ?
      loader = unittest.TestLoader()
  AttributeError: 'unittest' module has no attribute 'TestLoader'

But maybe I'm running the tests improperly; I haven't spent a lot of
time trying to figure this out. Regardless, it's only a one line fix
in a fairly isolated location. If it appears that this patch causes a
problem, I'd be surprised. Well, any problem other than aesthetic. As
I said, it lacks a bit of the elegance you might desire.

> I don't have any problem applying such a patch. I am a little confused,
> though. You say that cx_Oracle 3.1 builds acceptably under Python 2.1.3.
> I assume that means that you got a warning about PyString_FromFormat
> during compilation which turned into a dynamic link error at runtime?
> You can either post this on SourceForge or simply resend me the patch in
> an attachment -- either will do.

I didn't notice the first few times, because the Oracle (8.1.5)
headers generate several warnings of their own, but there it is:

  cx_Oracle.c: In function `MakeDSN':
  cx_Oracle.c:149: warning: implicit declaration of function `PyString_FromFormat'
  cx_Oracle.c:151: warning: return makes pointer from integer without a cast

I've sent the patch as an attachment this time. If you have any
questions, please let me know.

Thanks,
--G.

-- 
Geoff Gerrietts                                 <geoff at gerrietts net> 
"A man can't be too careful in the choice of his enemies." --Oscar Wilde

Re: [cx-oracle-users] Re: cx_Oracle Python utility

[Anthony T. <an...@co...>]

Its not a "feature" but rather a result of the fact that I only actually
use Python 2.2 and Python 2.3 now. I have no problem with a patch of
that nature. Have you run the test suite after building with that patch?
And does it pass completely (other than the Python 2.2 specific stuff)?

I don't have any problem applying such a patch. I am a little confused,
though. You say that cx_Oracle 3.1 builds acceptably under Python 2.1.3.
I assume that means that you got a warning about PyString_FromFormat
during compilation which turned into a dynamic link error at runtime?
You can either post this on SourceForge or simply resend me the patch in
an attachment -- either will do.

On Fri, 2003-08-29 at 17:15, Geoff Gerrietts wrote:
> cx_Oracle 3.1 builds acceptably under Python 2.1.3, but fails to run.
> Apparently 3.1 has used PyString_FromFormat, and that doesn't exist
> prior to some version of 2.2.
> 
> I have a patch -- it's not exactly elegant, but it gets the job done
> and appears to run correctly. I would submit as a bug and a proposed
> patch on sourceforge (and will if you tell me to) but I wasn't sure it
> wasn't actually a "feature".
> 
> Patch included below .sig.
> 
> Thanks,
> --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com