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

Re: [cx-oracle-users] Question concerning executemany() in cx_Oracle

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

On 2/6/07, matilda matilda <ma...@gr...> wrote:
> Hi all, hi Anthony,

Hi.

> while testing some unicode and encoding related stuff
> (yes Anthony, I work on that.  ;-) ) I struggled over

That's good. :-)

> the following code:
> --------------8<--------------------------------
> #!/usr/bin/python
> # -*- coding: utf8 -*-
> import sys
> import os
> import cx_Oracle as dbi
>
> utf8 =3D 'GERMAN_GERMANY.UTF8'
> latin1 =3D 'GERMAN_GERMANY.WE8ISO8859P1'
>
> if __name__ =3D=3D '__main__':
>     os.environ['NLS_LANG'] =3D latin1
>     con =3D dbi.connect('scott/tiger@twws')
>     cur =3D con.cursor()
>     a =3D u'=C4' * 4000
>     u =3D u'=DC' * 4000
>     o =3D u'=D6' * 4000
>     ae =3D a.encode('latin1')
>     ue =3D u.encode('latin1')
>     oe =3D o.encode('latin1')
>     print "Length ae:", len(ae)
>     print "Length ue:", len(ue)
>     print "Length oe:", len(oe)
>     list =3D ( (ae,), (ue,), (oe,) )
>     print type(list)
>     con.begin()
>     cur.executemany('insert into tst values (:val)', list)
>     con.commit()
>     cur.close()
>     con.close()
> --------------8<--------------------------------
>
> Running this code gives me an ugly exception:
> Traceback (most recent call last):
>   File "./i.py", line 26, in ?
>     cur.executemany('insert into tst values (:val)', list)
> TypeError: argument 2 must be list, not tuple
>
> I'm surprised: A tuple is a sequence and PEP249
> (http://www.python.org/dev/peps/pep-0249/) says:
> "[...] execute it against all parameter sequences or
>  mappings found in the sequence seq_of_parameters.[..]"
>
> So, what am I missing: Please enlight me.  :-))

First, your insert statement is specifying ":val" which is a named
parameter. You need to specify dictionaries, then. Or you can specify
":1" and use what you have defined. Second, you need to specify a list
as the top level as in

list =3D [ (ae,), (ue,), (oe,) ]

That should resolve your issues, I believe.

> Best regards
> Andreas Mock
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Question concerning executemany() in cx_Oracle

[matilda m. <ma...@gr...>]

Hi all, hi Anthony,

while testing some unicode and encoding related stuff
(yes Anthony, I work on that.  ;-) ) I struggled over
the following code:
--------------8<--------------------------------
#!/usr/bin/python
# -*- coding: utf8 -*-
import sys
import os
import cx_Oracle as dbi

utf8 =3D 'GERMAN_GERMANY.UTF8'
latin1 =3D 'GERMAN_GERMANY.WE8ISO8859P1'

if __name__ =3D=3D '__main__':
    os.environ['NLS_LANG'] =3D latin1
    con =3D dbi.connect('scott/tiger@twws')
    cur =3D con.cursor()
    a =3D u'=C3=84' * 4000
    u =3D u'=C3=9C' * 4000
    o =3D u'=C3=96' * 4000
    ae =3D a.encode('latin1')
    ue =3D u.encode('latin1')
    oe =3D o.encode('latin1')
    print "Length ae:", len(ae)
    print "Length ue:", len(ue)
    print "Length oe:", len(oe)
    list =3D ( (ae,), (ue,), (oe,) )
    print type(list)
    con.begin()
    cur.executemany('insert into tst values (:val)', list)
    con.commit()
    cur.close()
    con.close()
--------------8<--------------------------------

Running this code gives me an ugly exception:
Traceback (most recent call last):
  File "./i.py", line 26, in ?
    cur.executemany('insert into tst values (:val)', list)
TypeError: argument 2 must be list, not tuple

I'm surprised: A tuple is a sequence and PEP249
(http://www.python.org/dev/peps/pep-0249/) says:
"[...] execute it against all parameter sequences or
 mappings found in the sequence seq_of_parameters.[..]"

So, what am I missing: Please enlight me.  :-))

Best regards
Andreas Mock

Re: [cx-oracle-users] Fetching NaN, -Infinity and +Infinity from BINARY_FLOAT or BINARY_DOUBLE columns

[D.R. B. <da...@as...>]

Thank you very much Anthony!

We can wait for the next release and don't need a patch (I hope :).

Thanks again,

                                                   Danny


On Sat, Feb 03, 2007 at 12:23:16PM -0700, Anthony Tuininga wrote:
> Thank you for the simple test case. :-) I've managed to now implement
> this so that when native doubles or floats are returned from an Oracle
> 10g database they are automatically returned as a native float or
> double without any unnecessary conversion process. I have __NOT__ done
> the same for binding, however, because of the fact that you cannot use
> those types when using an Oracle 10g client against an Oracle 9i
> server. Did you want a patch for this or do you want to wait until I
> make the next release -- hopefully in the next couple of weeks.
> 
> On 2/1/07, D.R.   Boxhoorn <da...@as...> wrote:
> >
> > Good morning Anthony,
> >
> > Below you'll find a - hopefully - self-contained example to reproduce
> > the errors that can be caused by fetching NaN and Infinity as "binary"
> > doubles and floats.
> > I have the impression that this cannot be solved with a just few lines of
> > C code, but you are the expert here. :)
> >
> > Ciao,
> >
> >                                                    Danny
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > import struct, sys
> > import cx_Oracle
> >
> > connectstring = 'user/password@tnsname'
> >
> > # Clumsy way to obtain Infinity and NaN as float and double
> > floatinf,  = struct.unpack('f', struct.pack('L', 0x7F800000))
> > floatnan,  = struct.unpack('f', struct.pack('L', 0x7F800001))
> > doubleinf, = struct.unpack('d', struct.pack('Q', 0x7FF0000000000000L))
> > doublenan, = struct.unpack('d', struct.pack('Q', 0x7FF0000000000001L))
> >
> > assert str(floatinf) == 'inf', 'floatinf is not "inf", but %s' % floatinf
> > assert str(floatnan) == 'nan', 'floatnan is not "nan", but %s' % floatnan
> > assert str(doubleinf) == 'inf', 'doubleinf is not "inf", but %s' % doubleinf
> > assert str(doublenan) == 'nan', 'doublenan is not "inf", but %s' % doublenan
> >
> > # Get Infinity and NaN as constants to trigger exceptions
> > connection = cx_Oracle.connect(connectstring)
> > cursor = connection.cursor()
> >
> > for typeconversion in ['TO_BINARY_DOUBLE', 'TO_BINARY_FLOAT']:
> >     for number in ['floatinf', 'floatnan', 'doubleinf', 'doublenan']:
> >         print 'Trying %(typeconversion)s for %(number)s' % vars()
> >         cursor.execute('SELECT %(typeconversion)s(:1) FROM DUAL' % vars(), [eval(number)])
> >         try:
> >             cursor.fetchone()
> >             print 'Ok'
> >         except cx_Oracle.DatabaseError, e:
> >             print e
> >
> > cursor.close()
> > connection.close()
> >
> > # Expected output
> > # Trying TO_BINARY_DOUBLE for floatinf
> > # OCI-22065: number to text translation for the given format causes overflow
> > #
> > # Trying TO_BINARY_DOUBLE for floatnan
> > # ORA-01722: invalid number
> > #
> > # Trying TO_BINARY_DOUBLE for doubleinf
> > # OCI-22065: number to text translation for the given format causes overflow
> > #
> > # Trying TO_BINARY_DOUBLE for doublenan
> > # ORA-01722: invalid number
> > #
> > # Trying TO_BINARY_FLOAT for floatinf
> > # OCI-22065: number to text translation for the given format causes overflow
> > #
> > # Trying TO_BINARY_FLOAT for floatnan
> > # ORA-01722: invalid number
> > #
> > # Trying TO_BINARY_FLOAT for doubleinf
> > # OCI-22065: number to text translation for the given format causes overflow
> > #
> > # Trying TO_BINARY_FLOAT for doublenan
> > # ORA-01722: invalid number
> > --------------------------------------------------------------------------------
> >
> > On Wed, Jan 31, 2007 at 04:31:21PM -0700, Anthony Tuininga wrote:
> > > I'm assuming the attached script yields these errors but unfortunately
> > > I don't know which incantation is necessary (which parameters to pass)
> > > in order to get the associated error. Can you enlighten me? Thank you.
> > >
> > > On 1/12/07, D.R.   Boxhoorn <da...@as...> wrote:
> > > >
> > > >When fetching a NaN number (nan in Python) from a BINARY_FLOAT or
> > > >BINARY_DOUBLE
> > > >column, the following exception is raised.
> > > >
> > > >   Traceback (most recent call last):
> > > >     File "<stdin>", line 1, in ?
> > > >   cx_Oracle.DatabaseError: ORA-01722: invalid number
> > > >
> > > >Similary, fetching Infinity (inf in Python) from a BINARY_FLOAT or
> > > >BINARY_DOUBLE
> > > >column results in
> > > >
> > > >   Traceback (most recent call last):
> > > >     File "<stdin>", line 1, in ?
> > > >   cx_Oracle.DatabaseError: OCI-22065: number to text translation for the
> > > >   given format causes overflow
> > > >
> > > >Inserting Infinity and NaN, however, works flawlessly.
> > > >
> > > >
> > > >I've only tried this for cx_Oracle 4.2.1 & 4.1.2, Python 2.3 and Oracle
> > > >10gR2,
> > > >but it would not be surprising if other combinations show the same
> > > >behaviour.
> > > >
> > > >Does anyone have an idea for a solution or clever workaround?
> > > >
> > > >Thanks
> > > >
> > > >                                                   Danny
> > > >
> > > >
> > > >Using cx_Oracle 4.2.1
> > > >On Thu, Dec 07, 2006 at 09:30:17AM +0100, Henning von Bargen wrote:
> > > >> Hi Mark,
> > > >>
> > > >> pls try the following script:
> > > >> =============================================
> > > >>
> > > >> #!/bin/env python
> > > >> # -*- coding: iso-8859-1 -*-
> > > >> #
> > > >> import cx_Oracle
> > > >>
> > > >> # Sample 1
> > > >> def doAllCurs (curs, stmt, **args):
> > > >>     rset = curs.execute (stmt, **args)
> > > >>     for rec in curs:
> > > >>         yield rec
> > > >>     return
> > > >>
> > > >> # Sample 2
> > > >> def doAllConn (conn, stmt, **args):
> > > >>     curs = conn.cursor()
> > > >>     for rec in doAllCurs(curs, stmt, **args):
> > > >>         yield rec
> > > >>     curs.close()
> > > >>     return
> > > >>
> > > >> # Print All Records
> > > >> # This could  perhaps be recoded in a more functional programming style
> > > >> def printAll (curs, stmt, **args):
> > > >>     for rec in doAllCurs(curs, stmt, **args):
> > > >>         print rec
> > > >>
> > > >> def test (uid, query, **bindvars):
> > > >>     conn = cx_Oracle.connect(uid)
> > > >>     curs = conn.cursor()
> > > >>     printAll (curs, query, **bindvars)
> > > >>
> > > >>     print ""
> > > >>     print "The first 20 records as a list:"
> > > >>     print list (doAllCurs (curs, query, **bindvars))[:20]
> > > >>
> > > >>     curs.close()
> > > >>     conn.close()
> > > >>
> > > >> # Test me
> > > >> if __name__ == "__main__":
> > > >>     import sys
> > > >>     if len(sys.argv) > 1:
> > > >>         uid = sys.argv[1]
> > > >>         conditions = dict ([tuple(arg.split("=",1))
> > > >>                             for arg in sys.argv[2:]
> > > >>                            ])
> > > >>         query = """
> > > >> select object_name
> > > >>      , object_type
> > > >>   from user_objects
> > > >>  where 1=1"""
> > > >>         for nam,val in conditions.items():
> > > >>             query += ("\n and %s = :%s" % (nam,nam))
> > > >>         print "Query:"
> > > >>         print query
> > > >>         print "*" * 70
> > > >>         print "Bind Vars:"
> > > >>         for nam,val in conditions.items():
> > > >>             print "%-20s = %r" % (nam,val)
> > > >>         print "*" * 70
> > > >>         test (uid,  query, **conditions);
> > > >>     else:
> > > >>         print "Test me like this:"
> > > >>         print "%s uid/pwd@dbs object_type=TABLE" % sys.argv[0]
> > > >>
> > > >> =============================================
> > > >>
> > > >> Just save it as test.py, then call it like
> > > >> test.py userid/password@database object_type=TABLE
> > > >>
> > > >> or, with other condiditons:
> > > >> test.py userid/password@database object_type=TABLE object_name=XYZ
> > > >> (This will probably not return any results)
> > > >>
> > > >> HTH
> > > >> Henning
> > > >>
> > > >> -------------------------------------------------------------------------
> > > >> Take Surveys. Earn Cash. Influence the Future of IT
> > > >> Join SourceForge.net's Techsay panel and you'll get the chance to share
> > > >your
> > > >> opinions on IT & business topics through brief surveys - and earn cash
> > > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > >> _______________________________________________
> > > >> cx-oracle-users mailing list
> > > >> cx-...@li...
> > > >> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> > > >
> > > >-------------------------------------------------------------------------
> > > >Take Surveys. Earn Cash. Influence the Future of IT
> > > >Join SourceForge.net's Techsay panel and you'll get the chance to share
> > > >your
> > > >opinions on IT & business topics through brief surveys - and earn cash
> > > >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > >_______________________________________________
> > > >cx-oracle-users mailing list
> > > >cx-...@li...
> > > >https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> > > >
> >
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users

Re: [cx-oracle-users] Fetching NaN, -Infinity and +Infinity from BINARY_FLOAT or BINARY_DOUBLE columns

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

Thank you for the simple test case. :-) I've managed to now implement
this so that when native doubles or floats are returned from an Oracle
10g database they are automatically returned as a native float or
double without any unnecessary conversion process. I have __NOT__ done
the same for binding, however, because of the fact that you cannot use
those types when using an Oracle 10g client against an Oracle 9i
server. Did you want a patch for this or do you want to wait until I
make the next release -- hopefully in the next couple of weeks.

On 2/1/07, D.R.   Boxhoorn <da...@as...> wrote:
>
> Good morning Anthony,
>
> Below you'll find a - hopefully - self-contained example to reproduce
> the errors that can be caused by fetching NaN and Infinity as "binary"
> doubles and floats.
> I have the impression that this cannot be solved with a just few lines of
> C code, but you are the expert here. :)
>
> Ciao,
>
>                                                    Danny
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> import struct, sys
> import cx_Oracle
>
> connectstring = 'user/password@tnsname'
>
> # Clumsy way to obtain Infinity and NaN as float and double
> floatinf,  = struct.unpack('f', struct.pack('L', 0x7F800000))
> floatnan,  = struct.unpack('f', struct.pack('L', 0x7F800001))
> doubleinf, = struct.unpack('d', struct.pack('Q', 0x7FF0000000000000L))
> doublenan, = struct.unpack('d', struct.pack('Q', 0x7FF0000000000001L))
>
> assert str(floatinf) == 'inf', 'floatinf is not "inf", but %s' % floatinf
> assert str(floatnan) == 'nan', 'floatnan is not "nan", but %s' % floatnan
> assert str(doubleinf) == 'inf', 'doubleinf is not "inf", but %s' % doubleinf
> assert str(doublenan) == 'nan', 'doublenan is not "inf", but %s' % doublenan
>
> # Get Infinity and NaN as constants to trigger exceptions
> connection = cx_Oracle.connect(connectstring)
> cursor = connection.cursor()
>
> for typeconversion in ['TO_BINARY_DOUBLE', 'TO_BINARY_FLOAT']:
>     for number in ['floatinf', 'floatnan', 'doubleinf', 'doublenan']:
>         print 'Trying %(typeconversion)s for %(number)s' % vars()
>         cursor.execute('SELECT %(typeconversion)s(:1) FROM DUAL' % vars(), [eval(number)])
>         try:
>             cursor.fetchone()
>             print 'Ok'
>         except cx_Oracle.DatabaseError, e:
>             print e
>
> cursor.close()
> connection.close()
>
> # Expected output
> # Trying TO_BINARY_DOUBLE for floatinf
> # OCI-22065: number to text translation for the given format causes overflow
> #
> # Trying TO_BINARY_DOUBLE for floatnan
> # ORA-01722: invalid number
> #
> # Trying TO_BINARY_DOUBLE for doubleinf
> # OCI-22065: number to text translation for the given format causes overflow
> #
> # Trying TO_BINARY_DOUBLE for doublenan
> # ORA-01722: invalid number
> #
> # Trying TO_BINARY_FLOAT for floatinf
> # OCI-22065: number to text translation for the given format causes overflow
> #
> # Trying TO_BINARY_FLOAT for floatnan
> # ORA-01722: invalid number
> #
> # Trying TO_BINARY_FLOAT for doubleinf
> # OCI-22065: number to text translation for the given format causes overflow
> #
> # Trying TO_BINARY_FLOAT for doublenan
> # ORA-01722: invalid number
> --------------------------------------------------------------------------------
>
> On Wed, Jan 31, 2007 at 04:31:21PM -0700, Anthony Tuininga wrote:
> > I'm assuming the attached script yields these errors but unfortunately
> > I don't know which incantation is necessary (which parameters to pass)
> > in order to get the associated error. Can you enlighten me? Thank you.
> >
> > On 1/12/07, D.R.   Boxhoorn <da...@as...> wrote:
> > >
> > >When fetching a NaN number (nan in Python) from a BINARY_FLOAT or
> > >BINARY_DOUBLE
> > >column, the following exception is raised.
> > >
> > >   Traceback (most recent call last):
> > >     File "<stdin>", line 1, in ?
> > >   cx_Oracle.DatabaseError: ORA-01722: invalid number
> > >
> > >Similary, fetching Infinity (inf in Python) from a BINARY_FLOAT or
> > >BINARY_DOUBLE
> > >column results in
> > >
> > >   Traceback (most recent call last):
> > >     File "<stdin>", line 1, in ?
> > >   cx_Oracle.DatabaseError: OCI-22065: number to text translation for the
> > >   given format causes overflow
> > >
> > >Inserting Infinity and NaN, however, works flawlessly.
> > >
> > >
> > >I've only tried this for cx_Oracle 4.2.1 & 4.1.2, Python 2.3 and Oracle
> > >10gR2,
> > >but it would not be surprising if other combinations show the same
> > >behaviour.
> > >
> > >Does anyone have an idea for a solution or clever workaround?
> > >
> > >Thanks
> > >
> > >                                                   Danny
> > >
> > >
> > >Using cx_Oracle 4.2.1
> > >On Thu, Dec 07, 2006 at 09:30:17AM +0100, Henning von Bargen wrote:
> > >> Hi Mark,
> > >>
> > >> pls try the following script:
> > >> =============================================
> > >>
> > >> #!/bin/env python
> > >> # -*- coding: iso-8859-1 -*-
> > >> #
> > >> import cx_Oracle
> > >>
> > >> # Sample 1
> > >> def doAllCurs (curs, stmt, **args):
> > >>     rset = curs.execute (stmt, **args)
> > >>     for rec in curs:
> > >>         yield rec
> > >>     return
> > >>
> > >> # Sample 2
> > >> def doAllConn (conn, stmt, **args):
> > >>     curs = conn.cursor()
> > >>     for rec in doAllCurs(curs, stmt, **args):
> > >>         yield rec
> > >>     curs.close()
> > >>     return
> > >>
> > >> # Print All Records
> > >> # This could  perhaps be recoded in a more functional programming style
> > >> def printAll (curs, stmt, **args):
> > >>     for rec in doAllCurs(curs, stmt, **args):
> > >>         print rec
> > >>
> > >> def test (uid, query, **bindvars):
> > >>     conn = cx_Oracle.connect(uid)
> > >>     curs = conn.cursor()
> > >>     printAll (curs, query, **bindvars)
> > >>
> > >>     print ""
> > >>     print "The first 20 records as a list:"
> > >>     print list (doAllCurs (curs, query, **bindvars))[:20]
> > >>
> > >>     curs.close()
> > >>     conn.close()
> > >>
> > >> # Test me
> > >> if __name__ == "__main__":
> > >>     import sys
> > >>     if len(sys.argv) > 1:
> > >>         uid = sys.argv[1]
> > >>         conditions = dict ([tuple(arg.split("=",1))
> > >>                             for arg in sys.argv[2:]
> > >>                            ])
> > >>         query = """
> > >> select object_name
> > >>      , object_type
> > >>   from user_objects
> > >>  where 1=1"""
> > >>         for nam,val in conditions.items():
> > >>             query += ("\n and %s = :%s" % (nam,nam))
> > >>         print "Query:"
> > >>         print query
> > >>         print "*" * 70
> > >>         print "Bind Vars:"
> > >>         for nam,val in conditions.items():
> > >>             print "%-20s = %r" % (nam,val)
> > >>         print "*" * 70
> > >>         test (uid,  query, **conditions);
> > >>     else:
> > >>         print "Test me like this:"
> > >>         print "%s uid/pwd@dbs object_type=TABLE" % sys.argv[0]
> > >>
> > >> =============================================
> > >>
> > >> Just save it as test.py, then call it like
> > >> test.py userid/password@database object_type=TABLE
> > >>
> > >> or, with other condiditons:
> > >> test.py userid/password@database object_type=TABLE object_name=XYZ
> > >> (This will probably not return any results)
> > >>
> > >> HTH
> > >> Henning
> > >>
> > >> -------------------------------------------------------------------------
> > >> Take Surveys. Earn Cash. Influence the Future of IT
> > >> Join SourceForge.net's Techsay panel and you'll get the chance to share
> > >your
> > >> opinions on IT & business topics through brief surveys - and earn cash
> > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >> _______________________________________________
> > >> cx-oracle-users mailing list
> > >> cx-...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> > >
> > >-------------------------------------------------------------------------
> > >Take Surveys. Earn Cash. Influence the Future of IT
> > >Join SourceForge.net's Techsay panel and you'll get the chance to share
> > >your
> > >opinions on IT & business topics through brief surveys - and earn cash
> > >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >_______________________________________________
> > >cx-oracle-users mailing list
> > >cx-...@li...
> > >https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> > >
>

Re: [cx-oracle-users] Oracle crash with CLOB and threading

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

On 2/2/07, Roger Wenham <rog...@to...> wrote:
> Thanks for trying the program.

You're welcome. I like to eliminate problems such as the one you
discovered if I can at all do so.

> As the next step we have recompiled everything (Python cx_Oracle) to
> run under Solaris 10 64 Bit so that the breaking program can be run against
> Oracle 10g.
>
> The compilation was rather an adventure, but we eventually go a working Python
> 2.5. Cx_Oracle was more of a problem, and core dumped at the first cursor
> manipulation (BUS_ADRALN an alignment problem).
>
> I spent some time tracking the problem, and finally found it to be the retrieval of
> named variables, the PyDict_Next() call that was puking. I consulted the python
> documentation and everything looked OK, looking in the python header file
> though showed the second parameter to PyDict_Next() (the counter) was not integer,
> as in the python documentation and the cx_Oracle code, but Py_ssize_t. Changing the code to use this definition (I bet its not int on a 64 bit platform) fixed the problem of
> course.

Yes, I am aware of this problem. Its only a problem in 64-bit land, of
course. I have made the necessary changes and intend to release it
soon. I have been intending to release it for some time already but
simply haven't found the necessary time to do so -- and there are a
couple of other things I would like to address first.

> There are 3 instances of PyDict_Next() being used in cx_Oracle, all of them in Cursor.c,
> and just changing the second parameter declaration to be Py_ssize_t does the trick, and
> everything runs OK.

Correct.

> Having a working cx_Oracle, I ran the test program again, and got exactly the same problem
> as on the 32 bit system. The only difference is that I need to run more threads to break it
> now (20 instead of 10).

Interesting. I should maybe try with a higher number of threads as
well. Note that someone else discovered a problem with massive numbers
of connects and disconnects. I don't think they were using session
pooling, though. The solution for that will be in the next release as
well. Note that the workaround was to avoid calling close() on the
connection and instead let the normal reference counting mechanism
close and free the connection as needed.

> Checking the reason for the core dump shows an alignment problem again, so it can be
> that something being passed to or from the OCI by reference is type mismatched (remember
> you cant trust the Python documentation on this!). I would suggest that the Connection pool
> is a good place to look, as the problem does not occur when individual connections are used.

Hmm, unless you have a specific suggestion to look at I'm not sure
that is going to help since I can't reproduce the problem.

> I would like to go further with this, but I have a couple of pressing jobs that need to be done,
> so unfortunately I cant do much right now. I hope to get back th this problem soon. If you have
> time to take a peek at this in the meantime, I would be most grateful.

Understood. I'm not sure I'll have the time as well but I'll keep it in mind.

> Just for the record, we get the problem on:
>
> System 1:
>         Oracle 9i
>         Solaris 9 32 Bit
>         Python 2.2
>         Cx_Oracle 4.2.1
>
> System 2:
>         Oracle 10.2.0.1
>         Solaris 10 64 Bit
>         Python 2.5
>         Cx_Oracle 4.2.1

You might want to indicate specific versions of both the client and
the server. Occasionallly this information is critical. :-)

> Regards Roger
>
>   >>  I finally had a chance to try your program and did not run into any
>   >>  difficulties at all. The error you report is an Oracle crash and so is
>   >>  likely due to your particular Oracle software configuration. My own
>   >>  (which worked) was:
>
>   >>  Python 2.3 and Python 2.5
>   >>  Oracle Standard 9.2.0.5 (both server and client)
>   >>  Linux - Fedora Core 6 32-bit (both server and client)
>
>   >>  I would suggest scanning the Oracle bug database for the error you
>   >>  encountered. During my own traversals of that databse I have seen a
>   >>  number of problems related to CLOBs and segfaults like you indicated.
>   >>  I know that patchset 9.2.0.8 has been released -- its possible your
>   >>  issue has been addressed there.
>
>   >>  I unfortunately do not have access to an installation of the
>   >>  Enterprise edition running 64-bit anything -- so I can't help you in
>   >>  your specific configuration. Perhaps someone else on the list knows
>   >>  about this issue or can test it in an environment more similar to the
>   >>  poster's?
>
>   >>  On 1/26/07, Torsten Prange <Tor...@to...> wrote:
>   >>  > Hello,
>   >>  >
>   >>  > my collegue sent this mail today but has not subscribed to the mailing
>   >>   list
>   >>  > probably.
>   >>  >
>   >>  >
>   >>  > Mail from Rog...@to...:
>   >>  >
>   >>  > Hi,
>   >>  >
>   >>  > I am having some problems with cx_Oracle, threads and clob's and am
>   >>   looking for
>   >>  > some guidance.
>   >>  >
>   >>  > For the record:
>   >>  >         The system is "SunOS tmxd01 5.9 Generic_112233-10 sun4u sparc"
>   >>  >         cx_Oracle version is cx_Oracle-4.2.1
>   >>  >         Oracle version is: Oracle9i Enterprise Edition Release
> 9.2.0.7.0
>   >>   - 64bit
>   >>  > Production
>   >>  >         Python 2.2.2 (#10, Mar 19 2003, 14:11:47)
>   >>  >
>   >>  > When manipulating clobs in the database I occasionally got an Oracle
>   >>   error:
>   >>  >
>   >>  >         OCI-21500: internal error code, arguments: [nnnnn], [], [], [],
>   >>   [], [], [], []
>   >>  >
>   >>  > I have a test program that can now reproduce the problem at will, by
>   >>   repeatedly
>   >>  > inserting, selecting and deleting
>   >>  > on a table containing a clob from several threads. The error output
>   >>   looks like
>   >>  > this:
>   >>  >
>   >>  > OCI-21500: internal error code, arguments: [17099], [], [], [], [], [],
>   >>   [], []
>   >>  > Errors in file :
>   >>  > OCI-21500: internal error code, arguments: [17099], [], [], [], [], [],
>   >>   [], []
>   >>  >
>   >>  > ----- Call Stack Trace -----
>   >>  > NOTE: <PLT>+offset is used to represent that the
>   >>  >       function being called is offset bytes from
>   >>  >       the _PROCEDURE_LINKAGE_TABLE_.
>   >>  > calling              call     entry                argument values in
>   >>   hex
>   >>  > location             type     point                (? means dubious
>   >>   value)
>   >>  > -------------------- -------- --------------------
>   >>   ----------------------------
>   >>  > Segmentation Fault(coredump)
>   >>  >
>   >>  > Note that Oracle coredumps trying to print the stack trace.
>   >>  >
>   >>  > Change the data type from clob to varchar, and the problem disappears.
>   >>  >
>   >>  > I can also get rid of the problem by opening connections discreetly
>   >>   instead of
>   >>  > using the
>   >>  > cx_Oracle.SessionPool object, which surprised me rather.
>   >>  >
>   >>  > I am currently looking at the SessionPool, and clob object code in
>   >>   cx_Oracle
>   >>  > (Sadly, I am no expert with Python extensions),  maybe there is some
>   >>   issue with
>   >>  > reference counts?
>   >>  >
>   >>  > Any advice would be gratefully accepted.....
>   >>  >
>   >>  > The test program and sql script is attached to this e-mail
>   >>   (thread_test_clob.py
>   >>  > and tables_clob.sql)
>   >>  >
>   >>  > Thanks in advance...
>   >>  >
>   >>  > Roger
>   >>  >
>   >>  >
>   >>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Oracle crash with CLOB and threading

[Roger W. <rog...@to...>]

Thanks for trying the program.

As the next step we have recompiled everything (Python cx_Oracle) to
run under Solaris 10 64 Bit so that the breaking program can be run against
Oracle 10g.

The compilation was rather an adventure, but we eventually go a working Python
2.5. Cx_Oracle was more of a problem, and core dumped at the first cursor=20
manipulation (BUS_ADRALN an alignment problem).

I spent some time tracking the problem, and finally found it to be the =
retrieval of=20
named variables, the PyDict_Next() call that was puking. I consulted the python
documentation and everything looked OK, looking in the python header file=20
though showed the second parameter to PyDict_Next() (the counter) was not =
integer,=20
as in the python documentation and the cx_Oracle code, but Py_ssize_t. Changing =
the code to use this definition (I bet its not int on a 64 bit platform) fixed =
the problem of=20
course.

There are 3 instances of PyDict_Next() being used in cx_Oracle, all of them in =
Cursor.c,
and just changing the second parameter declaration to be Py_ssize_t does the =
trick, and
everything runs OK.

Having a working cx_Oracle, I ran the test program again, and got exactly the =
same problem
as on the 32 bit system. The only difference is that I need to run more threads =
to break it=20
now (20 instead of 10).=20

Checking the reason for the core dump shows an alignment problem again, so it =
can be
that something being passed to or from the OCI by reference is type mismatched =
(remember
you cant trust the Python documentation on this!). I would suggest that the =
Connection pool
is a good place to look, as the problem does not occur when individual =
connections are used.

I would like to go further with this, but I have a couple of pressing jobs that =
need to be done,=20
so unfortunately I cant do much right now. I hope to get back th this problem =
soon. If you have
time to take a peek at this in the meantime, I would be most grateful.

Just for the record, we get the problem on:

System 1:
	Oracle 9i
	Solaris 9 32 Bit
	Python 2.2
	Cx_Oracle 4.2.1

System 2:
	Oracle 10.2.0.1
	Solaris 10 64 Bit
	Python 2.5
	Cx_Oracle 4.2.1

Regards Roger

  >>  I finally had a chance to try your program and did not run into any
  >>  difficulties at all. The error you report is an Oracle crash and so is
  >>  likely due to your particular Oracle software configuration. My own
  >>  (which worked) was:

  >>  Python 2.3 and Python 2.5
  >>  Oracle Standard 9.2.0.5 (both server and client)
  >>  Linux - Fedora Core 6 32-bit (both server and client)

  >>  I would suggest scanning the Oracle bug database for the error you
  >>  encountered. During my own traversals of that databse I have seen a
  >>  number of problems related to CLOBs and segfaults like you indicated.
  >>  I know that patchset 9.2.0.8 has been released -- its possible your
  >>  issue has been addressed there.

  >>  I unfortunately do not have access to an installation of the
  >>  Enterprise edition running 64-bit anything -- so I can't help you in
  >>  your specific configuration. Perhaps someone else on the list knows
  >>  about this issue or can test it in an environment more similar to the
  >>  poster's?

  >>  On 1/26/07, Torsten Prange <Tor...@to...> wrote:
  >>  > Hello,
  >>  >
  >>  > my collegue sent this mail today but has not subscribed to the mailing
  >>   list
  >>  > probably.
  >>  >
  >>  >
  >>  > Mail from Rog...@to...:
  >>  >
  >>  > Hi,
  >>  >
  >>  > I am having some problems with cx_Oracle, threads and clob's and am
  >>   looking for
  >>  > some guidance.
  >>  >
  >>  > For the record:
  >>  >         The system is "SunOS tmxd01 5.9 Generic_112233-10 sun4u sparc"
  >>  >         cx_Oracle version is cx_Oracle-4.2.1
  >>  >         Oracle version is: Oracle9i Enterprise Edition Release=20
9.2.0.7.0
  >>   - 64bit
  >>  > Production
  >>  >         Python 2.2.2 (#10, Mar 19 2003, 14:11:47)
  >>  >
  >>  > When manipulating clobs in the database I occasionally got an Oracle
  >>   error:
  >>  >
  >>  >         OCI-21500: internal error code, arguments: [nnnnn], [], [], [],
  >>   [], [], [], []
  >>  >
  >>  > I have a test program that can now reproduce the problem at will, by
  >>   repeatedly
  >>  > inserting, selecting and deleting
  >>  > on a table containing a clob from several threads. The error output
  >>   looks like
  >>  > this:
  >>  >
  >>  > OCI-21500: internal error code, arguments: [17099], [], [], [], [], [],
  >>   [], []
  >>  > Errors in file :
  >>  > OCI-21500: internal error code, arguments: [17099], [], [], [], [], [],
  >>   [], []
  >>  >
  >>  > ----- Call Stack Trace -----
  >>  > NOTE: <PLT>+offset is used to represent that the
  >>  >       function being called is offset bytes from
  >>  >       the _PROCEDURE_LINKAGE_TABLE_.
  >>  > calling              call     entry                argument values in
  >>   hex
  >>  > location             type     point                (? means dubious
  >>   value)
  >>  > -------------------- -------- --------------------
  >>   ----------------------------
  >>  > Segmentation Fault(coredump)
  >>  >
  >>  > Note that Oracle coredumps trying to print the stack trace.
  >>  >
  >>  > Change the data type from clob to varchar, and the problem disappears.
  >>  >
  >>  > I can also get rid of the problem by opening connections discreetly
  >>   instead of
  >>  > using the
  >>  > cx_Oracle.SessionPool object, which surprised me rather.
  >>  >
  >>  > I am currently looking at the SessionPool, and clob object code in
  >>   cx_Oracle
  >>  > (Sadly, I am no expert with Python extensions),  maybe there is some
  >>   issue with
  >>  > reference counts?
  >>  >
  >>  > Any advice would be gratefully accepted.....
  >>  >
  >>  > The test program and sql script is attached to this e-mail
  >>   (thread_test_clob.py
  >>  > and tables_clob.sql)
  >>  >
  >>  > Thanks in advance...
  >>  >
  >>  > Roger
  >>  >
  >>  >
  >>  =20

Re: [cx-oracle-users] Freeing Temporary BLOBs

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

I managed to track this down to the fact that I was assuming that only
cx_Oracle itself was creating temporary lobs. I now check
OCILobIsTemporary() to determine if a LOB is temporary prior to
freeing it and call OCILobFreeTemporary() as needed. This will be in
the next release. If you need it sooner let me know privately and I
can send you a diff or a new binary for a particular platform.

On 2/1/07, Henning von Bargen <H.v...@t-...> wrote:
> Hello LOB experts,
>
> how can I free temporary LOBs before the session ends?
>
> I have a stored function that returns a temporary LOB.
> I can successfully get the content from Python,
> but when I am not able to free the memory (on the DB server)
> before the session ends.
>
> Here is an example:
>
> SQL:
>
> create or replace function test_blob (pi_size in binary_integer)
> return blob
> is
>   v_blob blob;
> begin
>   dbms_lob.createtemporary (v_blob, true, DBMS_LOB.SESSION);
>   dbms_lob.write (v_blob, 1, 1, utl_raw.cast_to_raw(rpad('AB', pi_size,
> 'X')));
>   return v_blob;
> end test_blob;
> /
>
> ---------------------
>
> Python
>
> import cx_Oracle
> import sys
>
> import logging
> logging.basicConfig(level=logging.INFO,
>                     format='%(asctime)s %(levelname)s %(message)s'
>                    )
> log = logging.getLogger()
>
> conn = cx_Oracle.connect ("someuser/password@ORCL")
> log.info ("connected")
>
> curs = conn.cursor()
> blob = curs.callfunc ("test_blob", cx_Oracle.BLOB, (200,))
> log.info ("FNC returned")
> content = blob.read()
> log.info ("BLOB data read")
> log.info ("data: %r", content)
>
> curs.execute ("select * from v$temporary_lobs");
> rset = curs.fetchall()
> log.info ("v$temporary_lobs=\n%r", rset)
>
> # THIS DOES NOT WORK, raises cx_Oracle.NotSupportedError:
> #curs.setinputsizes(blob=cx_Oracle.BLOB)  # does not help
> #curs.execute ("begin DBMS_LOB.FREETEMPORARY (:blob); end;", blob=blob)
>
> del blob
>
> curs.execute ("select * from v$temporary_lobs");
> rset = curs.fetchall()
> log.info ("v$temporary_lobs=\n%r", rset)
>
> curs.close()
> conn.close()
>
> You can see that even after deleting the blob on the python side,
> v$temporary_lobs still shows one LOB.
>
> I think OCILobFreeTemporary would be the right function here,
> but it seems not to be exposed to the python module.
>
> How to workaround this?
>
> Henning
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Fetching NaN, -Infinity and +Infinity from BINARY_FLOAT or BINARY_DOUBLE columns

[D.R. B. <da...@as...>]

Good morning Anthony,

Below you'll find a - hopefully - self-contained example to reproduce
the errors that can be caused by fetching NaN and Infinity as "binary"
doubles and floats.
I have the impression that this cannot be solved with a just few lines of
C code, but you are the expert here. :)

Ciao,

                                                   Danny

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
import struct, sys
import cx_Oracle

connectstring = 'user/password@tnsname'

# Clumsy way to obtain Infinity and NaN as float and double
floatinf,  = struct.unpack('f', struct.pack('L', 0x7F800000))
floatnan,  = struct.unpack('f', struct.pack('L', 0x7F800001))
doubleinf, = struct.unpack('d', struct.pack('Q', 0x7FF0000000000000L))
doublenan, = struct.unpack('d', struct.pack('Q', 0x7FF0000000000001L))

assert str(floatinf) == 'inf', 'floatinf is not "inf", but %s' % floatinf
assert str(floatnan) == 'nan', 'floatnan is not "nan", but %s' % floatnan
assert str(doubleinf) == 'inf', 'doubleinf is not "inf", but %s' % doubleinf
assert str(doublenan) == 'nan', 'doublenan is not "inf", but %s' % doublenan

# Get Infinity and NaN as constants to trigger exceptions
connection = cx_Oracle.connect(connectstring)
cursor = connection.cursor()

for typeconversion in ['TO_BINARY_DOUBLE', 'TO_BINARY_FLOAT']:
    for number in ['floatinf', 'floatnan', 'doubleinf', 'doublenan']:
        print 'Trying %(typeconversion)s for %(number)s' % vars()
        cursor.execute('SELECT %(typeconversion)s(:1) FROM DUAL' % vars(), [eval(number)])
        try:
            cursor.fetchone()
            print 'Ok'
        except cx_Oracle.DatabaseError, e:
            print e

cursor.close()
connection.close()

# Expected output
# Trying TO_BINARY_DOUBLE for floatinf
# OCI-22065: number to text translation for the given format causes overflow
# 
# Trying TO_BINARY_DOUBLE for floatnan
# ORA-01722: invalid number
# 
# Trying TO_BINARY_DOUBLE for doubleinf
# OCI-22065: number to text translation for the given format causes overflow
# 
# Trying TO_BINARY_DOUBLE for doublenan
# ORA-01722: invalid number
# 
# Trying TO_BINARY_FLOAT for floatinf
# OCI-22065: number to text translation for the given format causes overflow
# 
# Trying TO_BINARY_FLOAT for floatnan
# ORA-01722: invalid number
# 
# Trying TO_BINARY_FLOAT for doubleinf
# OCI-22065: number to text translation for the given format causes overflow
# 
# Trying TO_BINARY_FLOAT for doublenan
# ORA-01722: invalid number
--------------------------------------------------------------------------------

On Wed, Jan 31, 2007 at 04:31:21PM -0700, Anthony Tuininga wrote:
> I'm assuming the attached script yields these errors but unfortunately
> I don't know which incantation is necessary (which parameters to pass)
> in order to get the associated error. Can you enlighten me? Thank you.
> 
> On 1/12/07, D.R.   Boxhoorn <da...@as...> wrote:
> >
> >When fetching a NaN number (nan in Python) from a BINARY_FLOAT or 
> >BINARY_DOUBLE
> >column, the following exception is raised.
> >
> >   Traceback (most recent call last):
> >     File "<stdin>", line 1, in ?
> >   cx_Oracle.DatabaseError: ORA-01722: invalid number
> >
> >Similary, fetching Infinity (inf in Python) from a BINARY_FLOAT or 
> >BINARY_DOUBLE
> >column results in
> >
> >   Traceback (most recent call last):
> >     File "<stdin>", line 1, in ?
> >   cx_Oracle.DatabaseError: OCI-22065: number to text translation for the 
> >   given format causes overflow
> >
> >Inserting Infinity and NaN, however, works flawlessly.
> >
> >
> >I've only tried this for cx_Oracle 4.2.1 & 4.1.2, Python 2.3 and Oracle 
> >10gR2,
> >but it would not be surprising if other combinations show the same 
> >behaviour.
> >
> >Does anyone have an idea for a solution or clever workaround?
> >
> >Thanks
> >
> >                                                   Danny
> >
> >
> >Using cx_Oracle 4.2.1
> >On Thu, Dec 07, 2006 at 09:30:17AM +0100, Henning von Bargen wrote:
> >> Hi Mark,
> >>
> >> pls try the following script:
> >> =============================================
> >>
> >> #!/bin/env python
> >> # -*- coding: iso-8859-1 -*-
> >> #
> >> import cx_Oracle
> >>
> >> # Sample 1
> >> def doAllCurs (curs, stmt, **args):
> >>     rset = curs.execute (stmt, **args)
> >>     for rec in curs:
> >>         yield rec
> >>     return
> >>
> >> # Sample 2
> >> def doAllConn (conn, stmt, **args):
> >>     curs = conn.cursor()
> >>     for rec in doAllCurs(curs, stmt, **args):
> >>         yield rec
> >>     curs.close()
> >>     return
> >>
> >> # Print All Records
> >> # This could  perhaps be recoded in a more functional programming style
> >> def printAll (curs, stmt, **args):
> >>     for rec in doAllCurs(curs, stmt, **args):
> >>         print rec
> >>
> >> def test (uid, query, **bindvars):
> >>     conn = cx_Oracle.connect(uid)
> >>     curs = conn.cursor()
> >>     printAll (curs, query, **bindvars)
> >>
> >>     print ""
> >>     print "The first 20 records as a list:"
> >>     print list (doAllCurs (curs, query, **bindvars))[:20]
> >>
> >>     curs.close()
> >>     conn.close()
> >>
> >> # Test me
> >> if __name__ == "__main__":
> >>     import sys
> >>     if len(sys.argv) > 1:
> >>         uid = sys.argv[1]
> >>         conditions = dict ([tuple(arg.split("=",1))
> >>                             for arg in sys.argv[2:]
> >>                            ])
> >>         query = """
> >> select object_name
> >>      , object_type
> >>   from user_objects
> >>  where 1=1"""
> >>         for nam,val in conditions.items():
> >>             query += ("\n and %s = :%s" % (nam,nam))
> >>         print "Query:"
> >>         print query
> >>         print "*" * 70
> >>         print "Bind Vars:"
> >>         for nam,val in conditions.items():
> >>             print "%-20s = %r" % (nam,val)
> >>         print "*" * 70
> >>         test (uid,  query, **conditions);
> >>     else:
> >>         print "Test me like this:"
> >>         print "%s uid/pwd@dbs object_type=TABLE" % sys.argv[0]
> >>
> >> =============================================
> >>
> >> Just save it as test.py, then call it like
> >> test.py userid/password@database object_type=TABLE
> >>
> >> or, with other condiditons:
> >> test.py userid/password@database object_type=TABLE object_name=XYZ
> >> (This will probably not return any results)
> >>
> >> HTH
> >> Henning
> >>
> >> -------------------------------------------------------------------------
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> >your
> >> opinions on IT & business topics through brief surveys - and earn cash
> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> cx-oracle-users mailing list
> >> cx-...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> >
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share 
> >your
> >opinions on IT & business topics through brief surveys - and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >_______________________________________________
> >cx-oracle-users mailing list
> >cx-...@li...
> >https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> >

[cx-oracle-users] Freeing Temporary BLOBs

[Henning v. B. <H.v...@t-...>]

Hello LOB experts,

how can I free temporary LOBs before the session ends?

I have a stored function that returns a temporary LOB.
I can successfully get the content from Python,
but when I am not able to free the memory (on the DB server)
before the session ends.

Here is an example:

SQL:

create or replace function test_blob (pi_size in binary_integer)
return blob
is
  v_blob blob;
begin
  dbms_lob.createtemporary (v_blob, true, DBMS_LOB.SESSION);
  dbms_lob.write (v_blob, 1, 1, utl_raw.cast_to_raw(rpad('AB', pi_size,
'X')));
  return v_blob;
end test_blob;
/

---------------------

Python

import cx_Oracle
import sys

import logging
logging.basicConfig(level=3Dlogging.INFO,
                    format=3D'%(asctime)s %(levelname)s %(message)s'
                   )
log =3D logging.getLogger()

conn =3D cx_Oracle.connect ("someuser/password@ORCL")
log.info ("connected")

curs =3D conn.cursor()
blob =3D curs.callfunc ("test_blob", cx_Oracle.BLOB, (200,))
log.info ("FNC returned")
content =3D blob.read()
log.info ("BLOB data read")
log.info ("data: %r", content)

curs.execute ("select * from v$temporary_lobs");
rset =3D curs.fetchall()
log.info ("v$temporary_lobs=3D\n%r", rset)

# THIS DOES NOT WORK, raises cx_Oracle.NotSupportedError:
#curs.setinputsizes(blob=3Dcx_Oracle.BLOB)  # does not help
#curs.execute ("begin DBMS_LOB.FREETEMPORARY (:blob); end;", =
blob=3Dblob)

del blob

curs.execute ("select * from v$temporary_lobs");
rset =3D curs.fetchall()
log.info ("v$temporary_lobs=3D\n%r", rset)

curs.close()
conn.close()

You can see that even after deleting the blob on the python side,
v$temporary_lobs still shows one LOB.

I think OCILobFreeTemporary would be the right function here,
but it seems not to be exposed to the python module.

How to workaround this?

Henning

Re: [cx-oracle-users] Fetching NaN, -Infinity and +Infinity from BINARY_FLOAT or BINARY_DOUBLE columns

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

I'm assuming the attached script yields these errors but unfortunately
I don't know which incantation is necessary (which parameters to pass)
in order to get the associated error. Can you enlighten me? Thank you.

On 1/12/07, D.R.   Boxhoorn <da...@as...> wrote:
>
> When fetching a NaN number (nan in Python) from a BINARY_FLOAT or BINARY_DOUBLE
> column, the following exception is raised.
>
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in ?
>    cx_Oracle.DatabaseError: ORA-01722: invalid number
>
> Similary, fetching Infinity (inf in Python) from a BINARY_FLOAT or BINARY_DOUBLE
> column results in
>
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in ?
>    cx_Oracle.DatabaseError: OCI-22065: number to text translation for the given format causes overflow
>
> Inserting Infinity and NaN, however, works flawlessly.
>
>
> I've only tried this for cx_Oracle 4.2.1 & 4.1.2, Python 2.3 and Oracle 10gR2,
> but it would not be surprising if other combinations show the same behaviour.
>
> Does anyone have an idea for a solution or clever workaround?
>
> Thanks
>
>                                                    Danny
>
>
> Using cx_Oracle 4.2.1
> On Thu, Dec 07, 2006 at 09:30:17AM +0100, Henning von Bargen wrote:
> > Hi Mark,
> >
> > pls try the following script:
> > =============================================
> >
> > #!/bin/env python
> > # -*- coding: iso-8859-1 -*-
> > #
> > import cx_Oracle
> >
> > # Sample 1
> > def doAllCurs (curs, stmt, **args):
> >     rset = curs.execute (stmt, **args)
> >     for rec in curs:
> >         yield rec
> >     return
> >
> > # Sample 2
> > def doAllConn (conn, stmt, **args):
> >     curs = conn.cursor()
> >     for rec in doAllCurs(curs, stmt, **args):
> >         yield rec
> >     curs.close()
> >     return
> >
> > # Print All Records
> > # This could  perhaps be recoded in a more functional programming style
> > def printAll (curs, stmt, **args):
> >     for rec in doAllCurs(curs, stmt, **args):
> >         print rec
> >
> > def test (uid, query, **bindvars):
> >     conn = cx_Oracle.connect(uid)
> >     curs = conn.cursor()
> >     printAll (curs, query, **bindvars)
> >
> >     print ""
> >     print "The first 20 records as a list:"
> >     print list (doAllCurs (curs, query, **bindvars))[:20]
> >
> >     curs.close()
> >     conn.close()
> >
> > # Test me
> > if __name__ == "__main__":
> >     import sys
> >     if len(sys.argv) > 1:
> >         uid = sys.argv[1]
> >         conditions = dict ([tuple(arg.split("=",1))
> >                             for arg in sys.argv[2:]
> >                            ])
> >         query = """
> > select object_name
> >      , object_type
> >   from user_objects
> >  where 1=1"""
> >         for nam,val in conditions.items():
> >             query += ("\n and %s = :%s" % (nam,nam))
> >         print "Query:"
> >         print query
> >         print "*" * 70
> >         print "Bind Vars:"
> >         for nam,val in conditions.items():
> >             print "%-20s = %r" % (nam,val)
> >         print "*" * 70
> >         test (uid,  query, **conditions);
> >     else:
> >         print "Test me like this:"
> >         print "%s uid/pwd@dbs object_type=TABLE" % sys.argv[0]
> >
> > =============================================
> >
> > Just save it as test.py, then call it like
> > test.py userid/password@database object_type=TABLE
> >
> > or, with other condiditons:
> > test.py userid/password@database object_type=TABLE object_name=XYZ
> > (This will probably not return any results)
> >
> > HTH
> > Henning
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > cx-oracle-users mailing list
> > cx-...@li...
> > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Oracle crash with CLOB and threading

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

I finally had a chance to try your program and did not run into any
difficulties at all. The error you report is an Oracle crash and so is
likely due to your particular Oracle software configuration. My own
(which worked) was:

Python 2.3 and Python 2.5
Oracle Standard 9.2.0.5 (both server and client)
Linux - Fedora Core 6 32-bit (both server and client)

I would suggest scanning the Oracle bug database for the error you
encountered. During my own traversals of that databse I have seen a
number of problems related to CLOBs and segfaults like you indicated.
I know that patchset 9.2.0.8 has been released -- its possible your
issue has been addressed there.

I unfortunately do not have access to an installation of the
Enterprise edition running 64-bit anything -- so I can't help you in
your specific configuration. Perhaps someone else on the list knows
about this issue or can test it in an environment more similar to the
poster's?

On 1/26/07, Torsten Prange <Tor...@to...> wrote:
> Hello,
>
> my collegue sent this mail today but has not subscribed to the mailing list
> probably.
>
>
> Mail from Rog...@to...:
>
> Hi,
>
> I am having some problems with cx_Oracle, threads and clob's and am looking for
> some guidance.
>
> For the record:
>         The system is "SunOS tmxd01 5.9 Generic_112233-10 sun4u sparc"
>         cx_Oracle version is cx_Oracle-4.2.1
>         Oracle version is: Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit
> Production
>         Python 2.2.2 (#10, Mar 19 2003, 14:11:47)
>
> When manipulating clobs in the database I occasionally got an Oracle error:
>
>         OCI-21500: internal error code, arguments: [nnnnn], [], [], [], [], [], [], []
>
> I have a test program that can now reproduce the problem at will, by repeatedly
> inserting, selecting and deleting
> on a table containing a clob from several threads. The error output looks like
> this:
>
> OCI-21500: internal error code, arguments: [17099], [], [], [], [], [], [], []
> Errors in file :
> OCI-21500: internal error code, arguments: [17099], [], [], [], [], [], [], []
>
> ----- Call Stack Trace -----
> NOTE: <PLT>+offset is used to represent that the
>       function being called is offset bytes from
>       the _PROCEDURE_LINKAGE_TABLE_.
> calling              call     entry                argument values in hex
> location             type     point                (? means dubious value)
> -------------------- -------- -------------------- ----------------------------
> Segmentation Fault(coredump)
>
> Note that Oracle coredumps trying to print the stack trace.
>
> Change the data type from clob to varchar, and the problem disappears.
>
> I can also get rid of the problem by opening connections discreetly instead of
> using the
> cx_Oracle.SessionPool object, which surprised me rather.
>
> I am currently looking at the SessionPool, and clob object code in cx_Oracle
> (Sadly, I am no expert with Python extensions),  maybe there is some issue with
> reference counts?
>
> Any advice would be gratefully accepted.....
>
> The test program and sql script is attached to this e-mail (thread_test_clob.py
> and tables_clob.sql)
>
> Thanks in advance...
>
> Roger
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
>
>

[cx-oracle-users] Oracle crash with CLOB and threading

[Torsten P. <Tor...@to...>]

Hello,

my collegue sent this mail today but has not subscribed to the mailing list 
probably.


Mail from Rog...@to...:

Hi,

I am having some problems with cx_Oracle, threads and clob's and am looking for 
some guidance.

For the record:
	The system is "SunOS tmxd01 5.9 Generic_112233-10 sun4u sparc"
	cx_Oracle version is cx_Oracle-4.2.1
	Oracle version is: Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit 
Production
	Python 2.2.2 (#10, Mar 19 2003, 14:11:47)

When manipulating clobs in the database I occasionally got an Oracle error:

	OCI-21500: internal error code, arguments: [nnnnn], [], [], [], [], [], [], []

I have a test program that can now reproduce the problem at will, by repeatedly 
inserting, selecting and deleting 
on a table containing a clob from several threads. The error output looks like 
this:

OCI-21500: internal error code, arguments: [17099], [], [], [], [], [], [], []
Errors in file :
OCI-21500: internal error code, arguments: [17099], [], [], [], [], [], [], []

----- Call Stack Trace -----
NOTE: <PLT>+offset is used to represent that the
      function being called is offset bytes from
      the _PROCEDURE_LINKAGE_TABLE_.
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
Segmentation Fault(coredump)

Note that Oracle coredumps trying to print the stack trace.

Change the data type from clob to varchar, and the problem disappears.

I can also get rid of the problem by opening connections discreetly instead of 
using the 
cx_Oracle.SessionPool object, which surprised me rather.

I am currently looking at the SessionPool, and clob object code in cx_Oracle 
(Sadly, I am no expert with Python extensions),  maybe there is some issue with 
reference counts?

Any advice would be gratefully accepted.....

The test program and sql script is attached to this e-mail (thread_test_clob.py 
and tables_clob.sql)

Thanks in advance...

Roger 

Re: [cx-oracle-users] Documentation sources.

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

The "official" documentation is indeed reference material and not much
help when it comes to learning stuff. If you're looking for examples,
you can take a look at the cx_OracleTools project which contains a
number of utilities that aquire information from or manipulate data in
Oracle databases. The project is available at the same place that
cx_Oracle itself is. Here is the link in case you don't have it:

http://starship.python.net/crew/atuining

On 1/26/07, Mariano Mara <mm...@fi...> wrote:
> Hi everyone. I subscribed yesterday to the mailing list and I thought I
> might drop a line to say hi.
> First of all, my congrats to Anthony. cx_Oracle is a fine piece of work
> and the ultimate library when you want to combine oracle+python.
> I decided to learn python a few months ago and as I'm working 24x7 with
> oracle, kinda all my learning is oracle oriented.
>
> One thing I want to ask you guys is about the learning sources you have
> used when you started and you read when there are doubts: I'm using the
> official cx_Oracle documentation (I must say it lacks of some examples
> to ease the understading), the source code for cx_Oracle and this
> mailing list (since yesterday). Can you suggest additional sources that
> you find valuable?
>
> Is there any tutorial that shows the goodies of cx_Oracle with real life
> examples? This really would be nice.
>
> Thanks for your time, I see you around.
>
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Documentation sources.

[Mariano M. <mm...@fi...>]

Hi everyone. I subscribed yesterday to the mailing list and I thought I 
might drop a line to say hi.
First of all, my congrats to Anthony. cx_Oracle is a fine piece of work 
and the ultimate library when you want to combine oracle+python.
I decided to learn python a few months ago and as I'm working 24x7 with 
oracle, kinda all my learning is oracle oriented.

One thing I want to ask you guys is about the learning sources you have 
used when you started and you read when there are doubts: I'm using the 
official cx_Oracle documentation (I must say it lacks of some examples 
to ease the understading), the source code for cx_Oracle and this 
mailing list (since yesterday). Can you suggest additional sources that 
you find valuable?

Is there any tutorial that shows the goodies of cx_Oracle with real life 
examples? This really would be nice.

Thanks for your time, I see you around.

Re: [cx-oracle-users] Antw: Re: Antw: Re: Problem with internal buffer sizes

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

On 1/25/07, matilda matilda <ma...@gr...> wrote:
> Hi Anthony,
>
> >>> "Anthony Tuininga" <ant...@gm...> 25.01.07 17.12 Uhr
> >>>
> >I'm not sure what you mean by this. Could you explain further?
> >Currently cx_Oracle expects you to have to deal with everything. You
> >must pass in a stream of characters (not unicode) and you will get
> >back the same. That should be changed -- once I get my head around
> >everything, of course. :-)
>
> Ok, my conclusion until now:
> 1) At the moment you can forget python unicode strings
> and the direct handling of them concering binding them to
> oracle table columns.

Correct.

> 2) At the moment the allocated buffers for defined variables
> (db->client) and the buffer hint for the server side while
> binding (client->db) is done in a simple 1-to-1-fashion.
> That's ok, as long as the byte representation of a character
> string has the same length as the characterstring itself.

Correct.

> 3) Problems arise as soon as the byte representation is
> dfferent on both sides.
> a) While defining and allocating a variable on the client side
> (db->client) you should take care about the Attributes "isVariableSize"
> and "MaxBytesPerChar" for byte buffer allocation. This could be done
> quite soon, I think :-))

Yes, it can.

> b) While binding a variable (update/insert-statment) code should care
> about giving the server side a correct hint (better more than less) for
> the size of the server side byte representation after converting the
> incomming character stream to the byte representation of the
> related database encoding. (This is a db attribute. Don't know if
> there's
> a similar OCI call to get somthing like MaxBytePerChar).

This is uncertain as to whether or not this can be accomplished
without access to a unicode string in Python. If you have suggestions
as to which OCI calls to make, let me know.

> c) Forget the assumption that the python byte string can be max of 4000
> bytes to fit into a varchar2(4000) column. It can be more if the client
> side
> representation is bigger than the db side representation. This can be
> done
> really now! :-)))

Character semantics would allow for this. I'll have to see if this is
going to cause a problem at all.

> 4) Ask if I can help you. I really need the corrections and I hoped you
> could
> hit the right statements in your code much quicker than I can. Or I
> start to
> change your code and it will start to  be an ugly mess of c
> statements...
> ...then you can forget your nice object oriented coding style.  :-)

I can make the changes and test them somewhat but I would be happy if
you could test them more thorougly given your needs. If you're in a
very big hurry feel quite free to make any changes to your local copy
and then send me the patches (diffs). I can then integrate them
without having to figure everything out myself. What is your pleasure?

I think we should take this off the list now unless there is something
from which all would benefit. A final message in this thread can be
sent when the problems are resolved to your satisfaction.

> Best regards
> Andreas Mock
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Antw: Re: Antw: Re: Problem with internal buffer sizes

[matilda m. <ma...@gr...>]

Hi Anthony,

>>> "Anthony Tuininga" <ant...@gm...> 25.01.07 17.12 Uhr
>>>
>I'm not sure what you mean by this. Could you explain further?
>Currently cx_Oracle expects you to have to deal with everything. You
>must pass in a stream of characters (not unicode) and you will get
>back the same. That should be changed -- once I get my head around
>everything, of course. :-)

Ok, my conclusion until now:
1) At the moment you can forget python unicode strings
and the direct handling of them concering binding them to
oracle table columns.
2) At the moment the allocated buffers for defined variables
(db->client) and the buffer hint for the server side while
binding (client->db) is done in a simple 1-to-1-fashion.
That's ok, as long as the byte representation of a character
string has the same length as the characterstring itself.
3) Problems arise as soon as the byte representation is
dfferent on both sides.
a) While defining and allocating a variable on the client side
(db->client) you should take care about the Attributes "isVariableSize"
and "MaxBytesPerChar" for byte buffer allocation. This could be done
quite soon, I think :-))
b) While binding a variable (update/insert-statment) code should care
about giving the server side a correct hint (better more than less) for
the size of the server side byte representation after converting the
incomming character stream to the byte representation of the
related database encoding. (This is a db attribute. Don't know if
there's
a similar OCI call to get somthing like MaxBytePerChar).
c) Forget the assumption that the python byte string can be max of 4000
bytes to fit into a varchar2(4000) column. It can be more if the client
side
representation is bigger than the db side representation. This can be
done
really now! :-)))
4) Ask if I can help you. I really need the corrections and I hoped you
could
hit the right statements in your code much quicker than I can. Or I
start to
change your code and it will start to  be an ugly mess of c
statements...
...then you can forget your nice object oriented coding style.  :-)

Best regards
Andreas Mock

Re: [cx-oracle-users] Antw: Re: Problem with internal buffer sizes

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

On 1/25/07, matilda matilda <ma...@gr...> wrote:
> Hi Anthony,
>
> here's a link:
> http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci05bnd.htm#sthref756
>
> Sorry, I gave you an internal link.

No problem. That link is much better. I've seen it before but glossed
over it because it didn't concern me.... I'll have to read it a little
more carefully if I want to deal with character sets and unicode and
the like. :-)

> One question: Are you able to extebd the current
> functionality to let the whole thing work with
> different character encodings?

I'm not sure what you mean by this. Could you explain further?
Currently cx_Oracle expects you to have to deal with everything. You
must pass in a stream of characters (not unicode) and you will get
back the same. That should be changed -- once I get my head around
everything, of course. :-)

> Best regards
> Andreas Mock
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Antw: Re: Problem with internal buffer sizes

[matilda m. <ma...@gr...>]

Hi Anthony,

here's a link:
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci05bnd.htm#sthref756

Sorry, I gave you an internal link.

One question: Are you able to extebd the current
functionality to let the whole thing work with
different character encodings?

Best regards
Andreas Mock

Re: [cx-oracle-users] Antw: Re: Problem with internal buffer sizes

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

T24gMS8yNS8wNywgbWF0aWxkYSBtYXRpbGRhIDxtYXRpbGRhQGdyYW5kZWwuZGU+IHdyb3RlOgo+
IEhpIEFudGhvbnksCj4KPiB0aGFuayB5b3UgZm9yIHJlYWRpbmcgbXkgbG9uZyBtYWlsIGFuZCB0
YWtpbmcgdGhlIHRpbWUKPiB0byBsb29rIGF0IHRoaXMgcHJvYmxlbS4KCllvdSdyZSB3ZWxjb21l
LiBUaGFuayB5b3UgZm9yIHRha2luZyB0aGUgdGltZSB0byBleHBsYWluIGl0LiA6LSkKCj4gQXQg
dGhlIG1vbWVudCBJIGludmVzdGlnYXRlIGEgc2ltaWxhciBwcm9ibGVtLgo+IEkgY3JlYXRlZCBh
IGRhdGFiYXNlIHdpdGggYSBjaGFyYWN0ZXIgc2V0IG9mIFVURjguCj4gTm93IGl0IGdldHMgcmVh
bGx5IGZ1bm55LiA6LSkpCj4KPiBGb3IgZXhhbXBsZTogQSB0YWJsZQo+IGNyZWF0ZSB0YWJsZSB0
c3QgKAo+IGRhdGEgdmFyY2hhcjIoNDAwMCkKPiApCj4KPiBtZWFucyBub3csIHRoYXQgdGhlIGJ5
dGUgcmVwcmVzZW50YXRpb24gb2YKPiB0aGUgY2hhcmFjdGVyIHN0cmVhbSBnaXZlbiBieSB0aGUg
Y2xpZW50IGhhcyB0byBmaXQKPiBpbiA0MDAwIEJ5dGVzLiBTbyBJIGNhbiBzdG9yZSBvbmx5IGEg
bWF4aW11bQo+IG9mIDIwMDAgJ8OEJywgYmVjYXVzZSB0aGUgYnl0ZSByZXByZXNlbnRhdGlvbiBv
Zgo+ICfDhCcgbmVlZHMgMiBieXRlcy4KPgo+IE5vdyBzb21ldGhpbmcgc3RyYW5nZToKPiBBcyBz
b29uIGFzIEkgdHJ5IHRvIGluc2VydCAyMDAxICfDhCcgd2l0aCBjeF9PcmFjbGUsIEkgZ2V0IHRo
ZQo+IHN0cmFuZ2UgZXJyb3IgbWVzc2FnZToKPiBjeF9PcmFjbGUuRGF0YWJhc2VFcnJvcjogT1JB
LTAxNDYxOiBFaW4gTE9ORy1XZXJ0IGthbm4gbnVyIHp1ciBFaW5m4paSZ3VuZyBpbiBlaW5lIExP
TkctU3BhbHRlIGdlYnVuZGVuIHdlcmRlbgo+Cj4gV2hlbiBJIHRyeSB0aGF0IHdpdGggVE9BRCwg
SSBnZXQgdGhlIChtb3JlIGNvcnJlY3QpIGVycm9yCj4gbWVzc2FnZToKPiBPUkEtMDE3MDQ6IFpl
aWNoZW5mb2xnZSB6dSBsYW5nCj4KPiBJIGZvdW5kIHRoZSBmb2xsb3dpbmcgaGludCBpbiB0aGUg
T0NJIGRvY3VtZW50YXRpb246Cj4gaHR0cDovL2tpdGkvb3JhY2xlL29yYTEwZ3IyL2FwcGRldi4x
MDIvYjE0MjUwL29jaTA1Ym5kLmh0bSNpNDIyNzcwCj4gQ2hhcHRlciAnVXNpbmcgT0NJX0FUVFJf
TUFYREFUQV9TSVpFIEF0dHJpYnV0ZScKPiBhbmQgJ1VzaW5nIE9DSV9BVFRSX01BWENIQVJfU0la
RSBBdHRyaWJ1dGUnLgoKVGhlIGxpbmsgZG9lc24ndCB3b3JrIGZvciBtZSBiZWNhdXNlIGl0IHJl
ZmVyZW5jZXMgYSBob3N0IHdpdGhvdXQgYQpkb21haW4uIFBlcmhhcHMgeW91IGNhbiBwcm92aWRl
IGFuIGFsdGVybmF0aXZlIGxpbms/IE9yIEknbGwgc2ltcGx5CnNlYXJjaCB0aGUgZG9jdW1lbnRh
dGlvbiBmb3IgdGhlIGF0dHJpYnV0ZXMgaW4gcXVlc3Rpb24uCgo+IEFzIGZhciBhcyBJIHVuZGVy
c3Rvb2QsIHdpdGggdGhpcyBhdHRyaWJ1dGVzIHRvIGRlY2xhcmUgdGhlIGJ1ZmZlcgo+IGxlbmd0
aCAoaW4gYnl0ZXMsIGluIGNoYXIpIHdoaWNoIHNob3VsZCBiZSByZXNlcnZlZCBieSB0aGUgc2Vy
dmVyCj4gb24gc2VydmVyIHNpZGUgdG8gc3RvcmUgdGhlIGJ5dGUgcmVwcmVzZW50YXRpb24gKGRh
dGFiYXNlCj4gY29kZXNldCkgb2YgdGhlIGdpdmVuIHN0cmluZy4KPiAoZXhhbXBsZTogY2xpZW50
IExhdGluMTogMjAwMCAnw4QnID0gY2xpZW50IGJ1ZmZlciBzaXR6ZSAyMDAwIGJ5dGVzLAo+IHNl
cnZlciBzaWRlOiBVVEY4OiAyMDAwICfDhCcgPSBzZXJ2ZXIgYnVmZmVyIHNpemUgNDAwMCBieXRl
cykKCkhtbSwgdGhhdCBhc3N1bWVzIHRoYXQgd2UgYWxyZWFkeSBrbm93IHRoYXQgaW5mb3JtYXRp
b24sIG9mIGNvdXJzZS4KQW5kIGF0IHRoZSBtb21lbnQgY3hfT3JhY2xlIG9ubHkgYWNjZXB0cyBz
dHJpbmdzLCBub3QgdW5pY29kZS4gVGhhdAp3b3VsZCBtYWtlIGl0IGltcG9zc2libGUgdG8ga25v
dyBob3cgbWFueSBjaGFyYWN0ZXJzIHdlcmUgaW50ZW5kZWQuIEkKZG8gaGF2ZSBwbGFucyB0byBh
Y2NlcHQgdW5pY29kZSBidXQgdW5pY29kZSBpcyBub3QgbXkgc3Ryb25nIHBvaW50CihiZWluZyBh
biBFbmdsaXNoIHNwZWFraW5nIHBlcnNvbikgc28gSSdtIGdyb3BpbmcgYWJvdXQuIEkgYXBwcmVj
aWF0ZQp0aGUgaGludHMgSSd2ZSBiZWVuIHJlY2VpdmluZyBzbyBmYXIuIDotKQoKPiBJIGNvdWxk
bid0IGZpbmQgYW55IHVzZSBvZiBzZXR0aW5nIHRoZXNlIHR3byBhdHRyaWJ1dGVzIG9uIHRoZQo+
IGJpbmQgaGFuZGxlIGZvciBib3VuZCB2YXJpYWJsZXMgaW4gY3hfT3JhY2xlLiBQcm9iYWJseSB0
aGlzCj4gaXMgdGhlIHJlYXNvbiB3aHkgSSBnZXQgdGhlIHdyb25nIGVycm9yIG1lc3NhZ2UuCgpM
aWtlbHkuIFNlZSBhYm92ZSBhYm91dCB3aHkgc2ltcGx5IHNldHRpbmcgdGhvc2UgYXR0cmlidXRl
cyBpcyBub3QKZ29pbmcgaGVscCB5ZXQuCgo+IEkgaG9wZSB5b3UgZG9uJ3Qgc3RhcnQgdG8gcmVn
cmV0IGhhdmluZyB0YWxrZWQgdG8gbWUuICA6LSkpKQoKTm90IHlldC4gOi0pCgo+IEJlc3QgcmVn
YXJkcyBhbmQgdGhhbmsgeW91IGluIGFkdmFuY2UuCj4gQW5kcmVhcyBNb2NrCj4KPgo+Cj4gPj4+
ICJBbnRob255IFR1aW5pbmdhIiA8YW50aG9ueS50dWluaW5nYUBnbWFpbC5jb20+IDI1LjAxLjIw
MDcgMDU6MDYgPj4+Cj4gTG9va3MgbGlrZSB5b3UgbWlnaHQgYmUgcmlnaHQgb24gdGhpcy4gVGhl
IE9yYWNsZSBmb2xrcyBkbyBnaXZlIGEKPiB3YXJuaW5nIHRoYXQgc2ltcGx5IG11bHRpcGx5aW5n
IHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBleHBlY3RlZCBieQo+IHRoZSBtYXhpbXVtIG51bWJl
ciBvZiBieXRlcyBwZXIgY2hhcmFjdGVyIGNhbiByZXN1bHQgaW4gc2lnbmlmaWNhbnQKPiBtZW1v
cnkgdXNhZ2UgLS0gYnV0IGl0cyBndWFyYW50ZWVkIHRvIGJlIGNvcnJlY3Qgc28gSSB0aGluayBJ
J2xsIGRvCj4gaXQuIDotKSBVbmxlc3Mgc29tZW9uZSBlbHNlIGhhcyBhbm90aGVyIGJyaWxsaWFu
dCBpZGVhPz8KPgo+IE9uIDEvMjQvMDcsIG1hdGlsZGEgbWF0aWxkYSA8bWF0aWxkYUBncmFuZGVs
LmRlPiB3cm90ZToKPiA+IEhpIEFudGhvbnksCj4gPgo+ID4gaW4gbXkgb3BpbmlvbiB0aGUgY29k
ZSBvZiBjeF9PcmFjbGUgaXMgbm90IHJlYWx5IGNvcnJlY3Qgd2hlbgo+ID4gZGVhbGluZyB3aXRo
IGEgY2xpZW50IHNpZGUgZW5jb2Rpbmcgd2hpY2ggY2FuIHJlc3VsdCBpbiBtb3JlIHRoYW4KPiA+
IG9uZSBieXRlIHBlciBjaGFyYWN0ZXIuCj4gPgo+ID4gSSBpbnZlc3RlZCBzb21lIGhvdXJzIHRv
IGludmVzdGlnYXQgeW91ciBjb2RlIGFuZCBPcmFjbGUgT0NJCj4gPiBkb2N1bWVudGF0aW9uIHRv
IGdldCBjbG9zZXIgdG8gdGhlIHByb2JsZW0uIE5vdyBJIGhhdmUgc29tZQo+ID4gaGludHMgYW5k
IEkgaG9wZSBpdCB3aWxsIGhlbHAgeW91IHRvIGV4dGVuZCB0aGUgY29kZS4KPiA+Cj4gPiAxKSBT
emVuYXJpbyB0byByZXByb2R1Y2UgdGhlIGVycm9yOgo+ID4gRGF0YWJhc2UgaGFzIHRvIGJlIGlu
IGEgY2hhcmFjdGVyIHNldCwgd2hpY2ggY2FuIGdlbmVyYXRlCj4gPiB0d28gYnl0ZSBlbmNvZGlu
Z3MgaW4gVVRGLTguIEluIG1vc3QgY2FzZXMgTEFUSU4xIChha2EgV0U4SVNPODg1OVAxKQo+ID4g
aXMgb2suCj4gPgo+ID4gQ2hlY2s6Cj4gPiBzZWxlY3QgdmFsdWUgZnJvbSBubHNfZGF0YWJhc2Vf
cGFyYW1ldGVycyB3aGVyZSBwYXJhbWV0ZXIgPSAnTkxTX0NIQVJBQ1RFUlNFVCc7Cj4gPgo+ID4g
MikgQ3JlYXRlIHRoZSBmb2xsb3dpbmcgdGFibGU6Cj4gPiBjcmVhdGUgdGFibGUgdHN0ICgKPiA+
ICAgICAgICBkYXRhIHZhcmNoYXIyKDIpCj4gPiApCj4gPgo+ID4gaW5zZXJ0IGludG8gdHN0IHZh
bHVlcyAoJzHDhCcpOwo+ID4KPiA+IFRoc2kgc2hvdWxkIGZpdCBpbiB0aGUgdGFibGUsIGJlY2F1
c2UgJ8OEJyBjYW4gYmUgcmVwcmVzZW50ZWQKPiA+IGFzIG9uZSBieXRlIGluIExhdGluMS4KPiA+
Cj4gPiAzKSBUYWtlIHRoaXMgc2ltcGxlIHB5dGhvbiBjb2RlOgo+ID4gLS0tLS0tLS0tLS0tLTg8
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICMhL3Vzci9iaW4vcHl0aG9uCj4gPiAjIC0q
LSBjb2Rpbmc6IHV0ZjggLSotCj4gPiBpbXBvcnQgc3lzCj4gPiBpbXBvcnQgY3hfT3JhY2xlIGFz
IGRiaQo+ID4KPiA+IGlmIF9fbmFtZV9fID09ICdfX21haW5fXyc6Cj4gPiAgICAgY29uID0gZGJp
LmNvbm5lY3QoJ3Njb3R0L3RpZ2VyQHR3d3MnKQo+ID4gICAgIGN1ciA9IGNvbi5jdXJzb3IoKQo+
ID4gICAgIGN1ci5leGVjdXRlKCdzZWxlY3QgZGF0YSBmcm9tIHRzdCcpCj4gPiAgICAgcm93ID0g
Y3VyLmZldGNob25lKCkKPiA+ICAgICBwcmludCByb3cKPiA+ICAgICBjdXIuY2xvc2UoKQo+ID4g
ICAgIGNvbi5jbG9zZSgpCj4gPiAtLS0tLS0tLS0tLS0tODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQo+ID4KPiA+IDQpIE5vdyB0aGUgdGVzdHM6Cj4gPiBleHBvcnQgTkxTX0xBTkc9R0VSTUFO
X0dFUk1BTlkuV0U4SVNPODg1OVAxCj4gPiAgLi90c3QucHkKPiA+IE91dHB1dDogKCcxXHhjNCcs
KQo+ID4gRXZlcnl0aGluZyBpcyBmaW5lLCBiZWNhdXNlIG9uIHRoZSBjbGllbnQgc2lkZSBhIGJ1
ZmZlciBvZiBsZW5ndGggMiBpcwo+ID4gYWxsb2NhdGVkIGFuZCB0aGUgT0NJLWRlZmluZSBpcyBs
aW1pdGVkIHRvIDIuCj4gPiAtLS0KPiA+IGV4cG9ydCBOTFNfTEFORz1HRVJNQU5fR0VSTUFOWS5V
VEY4Cj4gPiAgLi90c3QucHkKPiA+IE91dHB1dDoKPiA+IFRyYWNlYmFjayAobW9zdCByZWNlbnQg
Y2FsbCBsYXN0KToKPiA+ICAgRmlsZSAiLi90c3QucHkiLCBsaW5lIDEwLCBpbiA/Cj4gPiAgICAg
cm93ID0gY3VyLmZldGNob25lKCkKPiA+IGN4X09yYWNsZS5EYXRhYmFzZUVycm9yOiBjb2x1bW4g
YXQgYXJyYXkgcG9zIDAgZmV0Y2hlZCB3aXRoIGVycm9yOiAxNDA2Cj4gPgo+ID4gUmVhc29uIChh
cyBmYXIgYXMgSSBjYW4gc2VlKTogMiBjaGFyYWN0ZXJzID0gMiBieXRlcyBvbiB0aGUgc2VydmVy
IHNpZGUKPiA+IGFyZSBleHBhbmRlZCB0byAyIGNoYXJhY3RlcnMgPSAzIGJ5dGVzIG9uIGNsaWVu
dCBzaWRlLiBPQ0kgaXMgdGVsbGluZyB0aGF0Cj4gPiB0aGUgbGVuZ3RoIChkYiBzaWRlKSBvZiB0
aGF0IHZhcmlhYmxlIGlzIDIsIHNvIDIgYnl0ZXMgYXJlIGFsbG9jYXRlZC4KPiA+IEZldGNoIGlz
IGRvbmUgaW4gYSAyIGJ5dGUgYXJyYXksIHRoYXQncyB0b28gc21hbGwgPT4gRXJyb3IgbWVzc2Fn
ZS4KPiA+Cj4gPiAoY29tbWVudDogSWYgSSB1c2UgdmFyY2hhcjIoMSksIGl0IHNlZW1zIHRvIHdv
cmsgYmVjYXVzZSB5b3UgYWRkCj4gPiBzb21lIGJ5dGVzIGluIGFueSBjYXNlIHRvIHRoZSBidWZm
ZXIgbGVuZ3RoLikKPiA+Cj4gPiA1KSBJIGhhdmUgc2VlbiwgdGhhdCB5b3UgbWFkZSB0aGUgYXNz
dW1wdGlvbiwgdGhhdCBzdHJpbmdzIChub3QgbG9icykgaGF2ZQo+ID4gYSBtYXhpbXVtIGxlbmd0
aCBvZiA0MDAwLgo+ID4gU3RyaW5nVmFyLmM6I2RlZmluZSBNQVhfU1RSSU5HX0xFTkdUSCAgICAg
ICAgICAgNDAwMAo+ID4gQXMgZmFyIGFzIEkgdW5kZXJzdG9vZCB0aGUgT3JhY2xlIGRvY3VtZW50
YXRpb24sIHRoaXMgaXMgdHJ1ZSBpbiB0ZXJtcwo+ID4gb2YgYnl0ZSByZXByZXNlbnRhdGlvbiBv
biB0aGUgZGIgc2lkZS4gVGhpcyBpcyBub3QgdHJ1ZSBvbiB0aGUgY2xpZW50IHNpZGUuCj4gPgo+
ID4gNikgSSBjaGFuZ2VkIHlvdXIgY29kZSB0byBnZXQgYSBzaW1wbGUgdHJhY2UgZmFjaWxpdHku
IElmIHlvdSBsaWtlIHRoYXQgY29kZQo+ID4gY29udGFjdCBtZS4gSSBmb3VuZCB0aGUgZm9sbG93
aW5nIHBhcmFncmFwaG9mIGNvZGUgaW4gRW52aXJvbm1lbnQuYzoKPiA+IC0tLS0tLS0tLS0tLS0t
ODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ICNpZmRlZiBPQ0lfTkxTX0NIQVJTRVRfTUFYQllU
RVNaCj4gPiAgICAgc3RhdHVzID0gT0NJTmxzTnVtZXJpY0luZm9HZXQoZW52aXJvbm1lbnQtPmhh
bmRsZSwKPiA+ICAgICAgICAgICAgIGVudmlyb25tZW50LT5lcnJvckhhbmRsZSwgJmVudmlyb25t
ZW50LT5tYXhCeXRlc1BlckNoYXJhY3RlciwKPiA+ICAgICAgICAgICAgIE9DSV9OTFNfQ0hBUlNF
VF9NQVhCWVRFU1opOwo+ID4gICAgIGlmIChFbnZpcm9ubWVudF9DaGVja0ZvckVycm9yKGVudmly
b25tZW50LCBzdGF0dXMsCj4gPiAgICAgICAgICAgICAiRW52aXJvbm1lbnRfTmV3KCk6IGdldCBt
YXggYnl0ZXMgcGVyIGNoYXJhY3RlciIpIDwgMCkgewo+ID4gICAgICAgICBQeV9ERUNSRUYoZW52
aXJvbm1lbnQpOwo+ID4gICAgICAgICByZXR1cm4gTlVMTDsKPiA+ICAgICB9Cj4gPgo+ID4gICAg
IC8vIGFjcXVpcmUgd2hldGhlciBjaGFyYWN0ZXIgc2V0IGlzIGZpeGVkIHdpZHRoCj4gPiAgICAg
c3RhdHVzID0gT0NJTmxzTnVtZXJpY0luZm9HZXQoZW52aXJvbm1lbnQtPmhhbmRsZSwKPiA+ICAg
ICAgICAgICAgIGVudmlyb25tZW50LT5lcnJvckhhbmRsZSwgJmVudmlyb25tZW50LT5maXhlZFdp
ZHRoLAo+ID4gICAgICAgICAgICAgT0NJX05MU19DSEFSU0VUX0ZJWEVEV0lEVEgpOwo+ID4gICAg
IGlmIChFbnZpcm9ubWVudF9DaGVja0ZvckVycm9yKGVudmlyb25tZW50LCBzdGF0dXMsCj4gPiAg
ICAgICAgICAgICAiRW52aXJvbm1lbnRfTmV3KCk6IGRldGVybWluZSBpZiBjaGFyc2V0IGlzIGZp
eGVkIHdpZHRoIikgPCAwKSB7Cj4gPiAgICAgICAgIFB5X0RFQ1JFRihlbnZpcm9ubWVudCk7Cj4g
PiAgICAgICAgIHJldHVybiBOVUxMOwo+ID4gICAgIH0KPiA+ICNlbmRpZgo+ID4gICAgIHRyYWNl
KCJFbnZpcm9ubWVudC5jOiBtYXhCeXRlc1BlckNoYXJhY3RlcjogJWRcbiIsIGVudmlyb25tZW50
LT5tYXhCeXRlc1BlckMKPiA+IGhhcmFjdGVyKTsgIC8vIHRoYXRzIGZyb20gbWUKPiA+Cj4gPiAt
LS0tLS0tLS0tLS0tLTg8LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiBUaGlzIHZhbHVlIHdhcyAz
IHdoZW4gSSB3b3JrZWQgd2l0aCBVVEY4Cj4gPiBhbmQgb25seSAxIHdoZW4gSSBjaG9zZSBMQVRJ
TjEuIEFzIGZhciBhcyBJIGNhbiBzZWUsIHlvdQo+ID4gdXNlIHRoaXMgdmFsdWUgb25seSB3aXRo
IGxvYnMuIElzIHRoYXQgdHJ1ZT8KPiA+IE5vdyBteSBoaW50OiBDb3VsZCB5b3UgYWRqdXN0IHRo
ZSBhbGxvY2F0ZWQgY2xpZW50IHNpZGUgYnVmZmVyIGxlbmd0aAo+ID4gd2l0aCBtYXhCeXRlc1Bl
ckNoYXJhY3Rlci4gQXMgSSdtIHRvdGFsbHkgbmV3IHRvIHlvdXIgY29kZSwKPiA+IEknbSBkb2lu
ZyByZWFsbHkgaGFyZCBmaW5kaW5nIGFsbCBwbGFjZXMgYW5kIG5vdCBmb3JnZXR0aW5nIHNvbWUK
PiA+IHNpZGUgZWZmZWN0cy4gU28sIEkgY2FuJ3QgZ2l2ZSB5b3UgYSBwYXRjaC4KPiA+IFVudGls
IG5vdyBJIG9ubHkgY2hlY2tlZCB0aGUgY29kZSBmb3IgImRlZmluZWQiIHZhcmlhYmxlcy4gVGhl
Cj4gPiBzYW1lIG11c3QgYmUgdHJ1ZSBmb3IgImJpbmQiIHZhcmlhYmxlcy4KPiA+IFNvLCBJJ20g
cHJldHR5IHN1cmUsIHRoYXQgdGhlIGZvbGxvd2luZyBjb2RlIHNuaXBwZXQgaXMgYWxzbyBub3Qg
cmVhbGx5Cj4gPiB2YWxpZDoKPiA+IC0tLS0tLS0tLS0tLS0tLQo+ID4gICAgIGVsc2UgaWYgKFB5
U3RyaW5nX0NoZWNrKHZhbHVlKSkgewo+ID4gICAgICAgICBzaXplID0gUHlTdHJpbmdfR0VUX1NJ
WkUodmFsdWUpOwo+ID4gICAgICAgICB0cmFjZSgiVmFyaWFibGUuYzogc2l6ZTogJWRcbiIsIHNp
emUpOwo+ID4gICAgICAgICBpZiAoc2l6ZSA+IE1BWF9TVFJJTkdfTEVOR1RIKQo+ID4gICAgICAg
ICAgICAgdmFyVHlwZSA9ICZ2dF9Mb25nU3RyaW5nOwo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tCj4g
PiBTemVuYXJpby4gSSBoYXZlIGEgbGl0dGUgdGFibGUgbGlrZToKPiA+IGNyZWF0ZSB0YWJsZSB0
c3QgKAo+ID4gZGF0YSB2YXJjaGFyMig0MDAwKQo+ID4gKQo+ID4gYW5kIGEgcHJvZ3JhbSBsaWtl
Ogo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiAjIS91c3IvYmluL3B5dGhvbgo+ID4gIyAtKi0g
Y29kaW5nOiB1dGY4IC0qLQo+ID4gaW1wb3J0IHN5cwo+ID4gaW1wb3J0IGN4X09yYWNsZSBhcyBk
YmkKPiA+Cj4gPiBpZiBfX25hbWVfXyA9PSAnX19tYWluX18nOgo+ID4gICAgIGNvbiA9IGRiaS5j
b25uZWN0KCdzY290dC90aWdlckB0d3dzJykKPiA+ICAgICBjdXIgPSBjb24uY3Vyc29yKCkKPiA+
ICAgICB2YWwgPSAnw4QnICogNDAwMAo+ID4gICAgIHByaW50ICdMZW5ndGg6ICcsIGxlbih2YWwp
Cj4gPiAgICAgY29uLmJlZ2luKCkKPiA+ICAgICBjdXIuZXhlY3V0ZSgnaW5zZXJ0IGludG8gdHN0
IHZhbHVlcyAoOnZhbCknLCAodmFsLCApKQo+ID4gICAgIGNvbi5jb21taXQoKQo+ID4gICAgIGN1
ci5jbG9zZSgpCj4gPiAgICAgY29uLmNsb3NlKCkKPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+ID4gVGhlIG1lbnRpb25lIGMgY29kZSBhYm92ZSBhc3N1bWVzIGluIGFueSBjYXNl
IHRoYXQKPiA+IEkgd2hhbnQgdG8gYmluZCBhIGxvbmcgdmFyaWFibGUuIEludGVyZXN0aW5nbHks
IGFzIGZhciBhcwo+ID4gdGhpcyBsb25nIHZhcmlhYmxlIGlzIHNtYWxsbGVyIG9yIGVxdWFsIHRv
IHRoZSBzaXplIG9mIHRoZQo+ID4gZGVzdGluYXRpb24gdmFyY2hhcjItY29sdW1uIChkYi1zaWRl
LCB3aGVuIHVzZWQgVVRGLTgKPiA+IDgwMDBieXRlPT40MDAwYnl0ZSksIHRoZSBpbnNlcnQgaXMg
ZG9uZSBldmVuIGlmIGl0J3MgYm91bmQKPiA+ICBhcyBsb25nIHR5cGUuIE9yY2FsZSBzZWVtcyAg
dG8gcGVyZm9ybSBhIHRyYW5zcGFyYW50IGNvbnZlcnNpb24uCj4gPiAgQXMgc29vbiBhcyB0aGUg
ZGVzdGluYXRpb24gaXMgdG9vIHNtYWxsIChMQVRJTkkxLCA4MDAwYnl0ZSA9PiA4MDAwYnl0ZSkK
PiA+IEkgZ2V0IGFuIGVycm9yIGFib3V0IGxvbmcgdmFyaWFibGUgYmluZGluZyB3aGF0IHdpbGwg
Y29uZnVzZSBzb21lb25lCj4gPiBub3Qga25vd2luZyB0aGF0IHlvdSBpbnRlcm5hbGx5IHN3aXRj
aGVkIHRvIGxvbmctYmluZGluZy4KPiA+IChUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwgbGFz
dCk6Cj4gPiAgIEZpbGUgIi4vaS5weSIsIGxpbmUgMTIsIGluID8KPiA+ICAgICBjdXIuZXhlY3V0
ZSgnaW5zZXJ0IGludG8gdHN0IHZhbHVlcyAoOnZhbCknLCAodmFsLCApKQo+ID4gY3hfT3JhY2xl
LkRhdGFiYXNlRXJyb3I6IE9SQS0wMTQ2MTogRWluIExPTkctV2VydCBrYW5uIG51ciB6dXIgRWlu
ZuKWkmd1bmcgaW4gZWluZSBMT05HLVNwYWx0ZSBnZWJ1bmRlbiB3ZXJkZW4KPiA+ICkKPiA+Cj4g
Pgo+ID4gNykgSW4gYW55IGNhc2UgdGhpcyBpcyBubyBjcml0aWNpc20gYWJvdXQgeW91ciB3b3Jr
LiBCdXQgSSB3b3VsZAo+ID4gbGlrZSB0byB3b3JrIHdpdGggVVRGLTggZW5jb2Rpbmcgb24gY2xp
ZW50IHNpZGUgYXMgdHJhbnNwYXJlbnRseQo+ID4gYXMgSSBjYW4gd2l0aCBMYXRpbjEuIEkgbGlr
ZSBjeF9PcmFjbGUgd2l0aCBweXRob24gbXVjaCBtb3JlCj4gPiB0aGFuIHRoZSBQZXJsIERCSSBz
dHVmZi4KPiA+IEFzIGxvbmcgYXMgdGhlIGRpZmZlcmVudCBzZW1hbnRpY3Mgb2YgY2hhcmFjdGVy
cyBhbmQgYnl0ZXMgaXMKPiA+IHRoZSB3YXkgaXQgaXMgaW4gcHl0aG9uIDIueCA8IHB5dGhvbiAz
MDAwLCB0aGUgYnl0ZSBhcnJheXMKPiA+IGRlbGl2ZXJlZCBieSBjeF9PcmFjbGUgdG8gcHl0aG9u
IHNob3VsZCByZWZsZWN0IHRoZSBjb3JyZWN0Cj4gPiBlbmNvZGluZyBvZiB0aGUgZGItY2xpZW50
LXNpZGUuCj4gPgo+ID4gSSBob3BlIHlvdSBjYW4gY29ycmVjdCB0aGlzIHByb2JsZW0uIEFzIHlv
dSBjYW4gc2VlLCBJIGxpa2UgdG8gaW52ZXN0Cj4gPiBhIGNvdXBsZSBvZiB0aW1lIHRvIGFzc2lz
dCBvciBoZWxwIHlvdS4KPiA+Cj4gPiBCZXN0IHJlZ2FyZHMKPiA+IEFuZHJlYXMgTW9jawo+ID4K
PiA+IFAuUy46IElnbm9yZSBhbGwgbWlzdGFrZXMgaW4gdGhpcyBFbmdsaXNoIHRleHQuCj4gPgo+
ID4KPiA+Cj4gPiA3KSBGb3VuZCB0aGUgZm9sbG93aW5nIGRvY3VtZW50YXRpb24gb2YgYnl0ZSBl
eHBhbnNpb24gd2hpbGUgdXNpbmcKPiA+IHVuaWNvZGUuIEFzIGZhciBhcyBJIGNhbiBzZWUsIHRo
ZSBtYXhpbXVtIGV4cGFuZGVkIGJ1ZmZlciBzaXplIGNhbiBiZQo+ID4gNDAwMCAqIDQgaW4gd29y
c3QgY2FzZS4KPiA+IGh0dHA6Ly93d3cuc3RhbmZvcmQuZWR1L2RlcHQvaXRzcy9kb2NzL29yYWNs
ZS8xMGcvc2VydmVyLjEwMS9iMTA3NDkvY2g3cHJvZ3J1bmljb2RlLmh0bSNpMTAwNjQ1Mgo+ID4K
PiA+Cj4gPgo+ID4gPj4+ICJBbnRob255IFR1aW5pbmdhIiA8YW50aG9ueS50dWluaW5nYUBnbWFp
bC5jb20+IDIzLjAxLjIwMDcgMTg6NTkgPj4+Cj4gPiBPbiAxLzIzLzA3LCBtYXRpbGRhIG1hdGls
ZGEgPG1hdGlsZGFAZ3JhbmRlbC5kZT4gd3JvdGU6Cj4gPgo+ID4gPiBBcyBmYXIgYXMgSSBrbm93
LCBzcWxwbHVzIGRvZXMgcmVhbGx5IGRvdWJsZSB0aGUgaW50ZXJuYWwgYnVmZmVycwo+ID4gPiB0
byBkbyB0aGUgY29tbXVuaWNhdGlvbiBmb3IgdGhlIGZvbGxvd2luZyBzemVuYXJpbzoKPiA+ID4g
REIgY2hhcmFjdGVyIHNldCBpcyBMYXRpbjEgPT4gSSBjYW4gc3RvcmUgYSBtYXhpbXVtIG9mIDQw
MDAKPiA+ID4gR2VybWFuIHVtbGF1dHMgdG8gdGhlIGEgc3RyaW5nIGNvbHVtbi4gVGhhdCByZXN1
bHRzIGluIDgwMDAKPiA+ID4gYnl0ZXMgb24gdGhlIGNsaWVudCBzaWRlIGlmIHRoZXJlIGlzIGEg
bXVsdGlieXRlIGVuY29kaW5nIGVuYWJsZWQuCj4gPgo+ID4gSG1tLCB0aGF0J3Mgd29ydGggdHJ5
aW5nLCBJIHN1cHBvc2UuIFdvdWxkIHlvdSBiZSBhYmxlIHRvIHByb3ZpZGUgYQo+ID4gc21hbGwg
dGVzdCBjYXNlIHRoYXQgZGVtb25zdHJhdGVzIHRoZSBwcm9ibGVtPyBTb21ldGhpbmcgdGhhdCBo
YXMgNDAwMAo+ID4gY2hhcmFjdGVycyBpbiBpdCB3aGljaCB3aWxsIGFjdHVhbGx5IHJlc3VsdCBp
biBjb25zaWRlcmFibHkgbGFyZ2VyCj4gPiBudW1iZXIgb2YgYnl0ZXMuIEkgY2FuIHRoZW4gdHJ5
IHRoYXQgYW5kIHNlZSBpZiB5b3VyIGFzc3VtcHRpb24gaXMKPiA+IGNvcnJlY3QuIElmIGl0IGlz
LCB0aGVuIHRoZSBtYXR0ZXIgaXMgZmFpcmx5IHNpbXBsZSB0byBhZGRyZXNzLgo+ID4KPiA+Cj4g
PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCj4gPiBUYWtlIFN1cnZleXMuIEVhcm4gQ2FzaC4gSW5mbHVlbmNl
IHRoZSBGdXR1cmUgb2YgSVQKPiA+IEpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5l
bCBhbmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKPiA+IG9waW5pb25zIG9u
IElUICYgYnVzaW5lc3MgdG9waWNzIHRocm91Z2ggYnJpZWYgc3VydmV5cyAtIGFuZCBlYXJuIGNh
c2gKPiA+IGh0dHA6Ly93d3cudGVjaHNheS5jb20vZGVmYXVsdC5waHA/cGFnZT1qb2luLnBocCZw
PXNvdXJjZWZvcmdlJkNJRD1ERVZERVYKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCj4gPiBjeC1vcmFjbGUtdXNlcnMgbWFpbGluZyBsaXN0Cj4gPiBj
eC1vcmFjbGUtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gPiBodHRwczovL2xpc3RzLnNv
dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9jeC1vcmFjbGUtdXNlcnMKPiA+Cj4gLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQo+IFRha2UgU3VydmV5cy4gRWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVy
ZSBvZiBJVAo+IEpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQgeW91J2xs
IGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNz
IHRvcGljcyB0aHJvdWdoIGJyaWVmIHN1cnZleXMgLSBhbmQgZWFybiBjYXNoCj4gaHR0cDovL3d3
dy50ZWNoc2F5LmNvbS9kZWZhdWx0LnBocD9wYWdlPWpvaW4ucGhwJnA9c291cmNlZm9yZ2UmQ0lE
PURFVkRFVgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Cj4gY3gtb3JhY2xlLXVzZXJzIG1haWxpbmcgbGlzdAo+IGN4LW9yYWNsZS11c2Vyc0BsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0
aW5mby9jeC1vcmFjbGUtdXNlcnMKPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBUYWtlIFN1cnZleXMu
IEVhcm4gQ2FzaC4gSW5mbHVlbmNlIHRoZSBGdXR1cmUgb2YgSVQKPiBKb2luIFNvdXJjZUZvcmdl
Lm5ldCdzIFRlY2hzYXkgcGFuZWwgYW5kIHlvdSdsbCBnZXQgdGhlIGNoYW5jZSB0byBzaGFyZSB5
b3VyCj4gb3BpbmlvbnMgb24gSVQgJiBidXNpbmVzcyB0b3BpY3MgdGhyb3VnaCBicmllZiBzdXJ2
ZXlzIC0gYW5kIGVhcm4gY2FzaAo+IGh0dHA6Ly93d3cudGVjaHNheS5jb20vZGVmYXVsdC5waHA/
cGFnZT1qb2luLnBocCZwPXNvdXJjZWZvcmdlJkNJRD1ERVZERVYKPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGN4LW9yYWNsZS11c2VycyBtYWlsaW5n
IGxpc3QKPiBjeC1vcmFjbGUtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0cHM6Ly9s
aXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vY3gtb3JhY2xlLXVzZXJzCj4K

[cx-oracle-users] Antw: Re: Problem with internal buffer sizes

[matilda m. <ma...@gr...>]

Hi Anthony,

thank you for reading my long mail and taking the time
to look at this problem.

At the moment I investigate a similar problem.
I created a database with a character set of UTF8.
Now it gets really funny. :-))

For example: A table
create table tst (
data varchar2(4000)
)

means now, that the byte representation of
the character stream given by the client has to fit=20
in 4000 Bytes. So I can store only a maximum
of 2000 '=C3=84', because the byte representation of
'=C3=84' needs 2 bytes.

Now something strange:
As soon as I try to insert 2001 '=C3=84' with cx_Oracle, I get the
strange error message:
cx_Oracle.DatabaseError: ORA-01461: Ein LONG-Wert kann nur zur Einf=E2=96=
=92gung in eine LONG-Spalte gebunden werden

When I try that with TOAD, I get the (more correct) error
message:
ORA-01704: Zeichenfolge zu lang

I found the following hint in the OCI documentation:
http://kiti/oracle/ora10gr2/appdev.102/b14250/oci05bnd.htm#i422770=20
Chapter 'Using OCI_ATTR_MAXDATA_SIZE Attribute'
and 'Using OCI_ATTR_MAXCHAR_SIZE Attribute'.

As far as I understood, with this attributes to declare the buffer
length (in bytes, in char) which should be reserved by the server
on server side to store the byte representation (database
codeset) of the given string.
(example: client Latin1: 2000 '=C3=84' =3D client buffer sitze 2000 =
bytes,=20
server side: UTF8: 2000 '=C3=84' =3D server buffer size 4000 bytes)

I couldn't find any use of setting these two attributes on the
bind handle for bound variables in cx_Oracle. Probably this
is the reason why I get the wrong error message.

I hope you don't start to regret having talked to me.  :-)))

Best regards and thank you in advance.
Andreas Mock



>>> "Anthony Tuininga" <ant...@gm...> 25.01.2007 05:06 >>>
Looks like you might be right on this. The Oracle folks do give a
warning that simply multiplying the number of characters expected by
the maximum number of bytes per character can result in significant
memory usage -- but its guaranteed to be correct so I think I'll do
it. :-) Unless someone else has another brilliant idea??

On 1/24/07, matilda matilda <ma...@gr...> wrote:
> Hi Anthony,
>
> in my opinion the code of cx_Oracle is not realy correct when
> dealing with a client side encoding which can result in more than
> one byte per character.
>
> I invested some hours to investigat your code and Oracle OCI
> documentation to get closer to the problem. Now I have some
> hints and I hope it will help you to extend the code.
>
> 1) Szenario to reproduce the error:
> Database has to be in a character set, which can generate
> two byte encodings in UTF-8. In most cases LATIN1 (aka WE8ISO8859P1)
> is ok.
>
> Check:
> select value from nls_database_parameters where parameter =3D 'NLS_CHARAC=
TERSET';
>
> 2) Create the following table:
> create table tst (
>        data varchar2(2)
> )
>
> insert into tst values ('1=C3=84');
>
> Thsi should fit in the table, because '=C3=84' can be represented
> as one byte in Latin1.
>
> 3) Take this simple python code:
> -------------8<--------------------------
> #!/usr/bin/python
> # -*- coding: utf8 -*-
> import sys
> import cx_Oracle as dbi
>
> if __name__ =3D=3D '__main__':
>     con =3D dbi.connect('scott/tiger@twws')
>     cur =3D con.cursor()
>     cur.execute('select data from tst')
>     row =3D cur.fetchone()
>     print row
>     cur.close()
>     con.close()
> -------------8<--------------------------
>
> 4) Now the tests:
> export NLS_LANG=3DGERMAN_GERMANY.WE8ISO8859P1
>  ./tst.py
> Output: ('1\xc4',)
> Everything is fine, because on the client side a buffer of length 2 is
> allocated and the OCI-define is limited to 2.
> ---
> export NLS_LANG=3DGERMAN_GERMANY.UTF8
>  ./tst.py
> Output:
> Traceback (most recent call last):
>   File "./tst.py", line 10, in ?
>     row =3D cur.fetchone()
> cx_Oracle.DatabaseError: column at array pos 0 fetched with error: 1406
>
> Reason (as far as I can see): 2 characters =3D 2 bytes on the server =
side
> are expanded to 2 characters =3D 3 bytes on client side. OCI is telling =
that
> the length (db side) of that variable is 2, so 2 bytes are allocated.
> Fetch is done in a 2 byte array, that's too small =3D> Error message.
>
> (comment: If I use varchar2(1), it seems to work because you add
> some bytes in any case to the buffer length.)
>
> 5) I have seen, that you made the assumption, that strings (not lobs) =
have
> a maximum length of 4000.
> StringVar.c:#define MAX_STRING_LENGTH           4000
> As far as I understood the Oracle documentation, this is true in terms
> of byte representation on the db side. This is not true on the client =
side.
>
> 6) I changed your code to get a simple trace facility. If you like that =
code
> contact me. I found the following paragraphof code in Environment.c:
> --------------8<---------------------
> #ifdef OCI_NLS_CHARSET_MAXBYTESZ
>     status =3D OCINlsNumericInfoGet(environment->handle,
>             environment->errorHandle, &environment->maxBytesPerCharacter,=

>             OCI_NLS_CHARSET_MAXBYTESZ);
>     if (Environment_CheckForError(environment, status,
>             "Environment_New(): get max bytes per character") < 0) {
>         Py_DECREF(environment);
>         return NULL;
>     }
>
>     // acquire whether character set is fixed width
>     status =3D OCINlsNumericInfoGet(environment->handle,
>             environment->errorHandle, &environment->fixedWidth,
>             OCI_NLS_CHARSET_FIXEDWIDTH);
>     if (Environment_CheckForError(environment, status,
>             "Environment_New(): determine if charset is fixed width") < =
0) {
>         Py_DECREF(environment);
>         return NULL;
>     }
> #endif
>     trace("Environment.c: maxBytesPerCharacter: %d\n", environment->maxBy=
tesPerC
> haracter);  // thats from me
>
> --------------8<---------------------
> This value was 3 when I worked with UTF8
> and only 1 when I chose LATIN1. As far as I can see, you
> use this value only with lobs. Is that true?
> Now my hint: Could you adjust the allocated client side buffer length
> with maxBytesPerCharacter. As I'm totally new to your code,
> I'm doing really hard finding all places and not forgetting some
> side effects. So, I can't give you a patch.
> Until now I only checked the code for "defined" variables. The
> same must be true for "bind" variables.
> So, I'm pretty sure, that the following code snippet is also not really
> valid:
> ---------------
>     else if (PyString_Check(value)) {
>         size =3D PyString_GET_SIZE(value);
>         trace("Variable.c: size: %d\n", size);
>         if (size > MAX_STRING_LENGTH)
>             varType =3D &vt_LongString;
> ------------------
> Szenario. I have a litte table like:
> create table tst (
> data varchar2(4000)
> )
> and a program like:
> ------------------
> #!/usr/bin/python
> # -*- coding: utf8 -*-
> import sys
> import cx_Oracle as dbi
>
> if __name__ =3D=3D '__main__':
>     con =3D dbi.connect('scott/tiger@twws')
>     cur =3D con.cursor()
>     val =3D '=C3=84' * 4000
>     print 'Length: ', len(val)
>     con.begin()
>     cur.execute('insert into tst values (:val)', (val, ))
>     con.commit()
>     cur.close()
>     con.close()
> ------------------------------
> The mentione c code above assumes in any case that
> I whant to bind a long variable. Interestingly, as far as
> this long variable is smalller or equal to the size of the
> destination varchar2-column (db-side, when used UTF-8
> 8000byte=3D>4000byte), the insert is done even if it's bound
>  as long type. Orcale seems  to perform a transparant conversion.
>  As soon as the destination is too small (LATINI1, 8000byte =3D> =
8000byte)
> I get an error about long variable binding what will confuse someone
> not knowing that you internally switched to long-binding.
> (Traceback (most recent call last):
>   File "./i.py", line 12, in ?
>     cur.execute('insert into tst values (:val)', (val, ))
> cx_Oracle.DatabaseError: ORA-01461: Ein LONG-Wert kann nur zur Einf=E2=96=
=92gung in eine LONG-Spalte gebunden werden
> )
>
>
> 7) In any case this is no criticism about your work. But I would
> like to work with UTF-8 encoding on client side as transparently
> as I can with Latin1. I like cx_Oracle with python much more
> than the Perl DBI stuff.
> As long as the different semantics of characters and bytes is
> the way it is in python 2.x < python 3000, the byte arrays
> delivered by cx_Oracle to python should reflect the correct
> encoding of the db-client-side.
>
> I hope you can correct this problem. As you can see, I like to invest
> a couple of time to assist or help you.
>
> Best regards
> Andreas Mock
>
> P.S.: Ignore all mistakes in this English text.
>
>
>
> 7) Found the following documentation of byte expansion while using
> unicode. As far as I can see, the maximum expanded buffer size can be
> 4000 * 4 in worst case.
> http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10749/ch7pr=
ogrunicode.htm#i1006452=20
>
>
>
> >>> "Anthony Tuininga" <ant...@gm...> 23.01.2007 18:59 >>>
> On 1/23/07, matilda matilda <ma...@gr...> wrote:
>
> > As far as I know, sqlplus does really double the internal buffers
> > to do the communication for the following szenario:
> > DB character set is Latin1 =3D> I can store a maximum of 4000
> > German umlauts to the a string column. That results in 8000
> > bytes on the client side if there is a multibyte encoding enabled.
>
> Hmm, that's worth trying, I suppose. Would you be able to provide a
> small test case that demonstrates the problem? Something that has 4000
> characters in it which will actually result in considerably larger
> number of bytes. I can then try that and see if your assumption is
> correct. If it is, then the matter is fairly simple to address.
>
>
> -------------------------------------------------------------------------=

> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV=20
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...=20
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users=20
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV=20
_______________________________________________
cx-oracle-users mailing list
cx-...@li...=20
https://lists.sourceforge.net/lists/listinfo/cx-oracle-users

Re: [cx-oracle-users] Problem with internal buffer sizes

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

TG9va3MgbGlrZSB5b3UgbWlnaHQgYmUgcmlnaHQgb24gdGhpcy4gVGhlIE9yYWNsZSBmb2xrcyBk
byBnaXZlIGEKd2FybmluZyB0aGF0IHNpbXBseSBtdWx0aXBseWluZyB0aGUgbnVtYmVyIG9mIGNo
YXJhY3RlcnMgZXhwZWN0ZWQgYnkKdGhlIG1heGltdW0gbnVtYmVyIG9mIGJ5dGVzIHBlciBjaGFy
YWN0ZXIgY2FuIHJlc3VsdCBpbiBzaWduaWZpY2FudAptZW1vcnkgdXNhZ2UgLS0gYnV0IGl0cyBn
dWFyYW50ZWVkIHRvIGJlIGNvcnJlY3Qgc28gSSB0aGluayBJJ2xsIGRvCml0LiA6LSkgVW5sZXNz
IHNvbWVvbmUgZWxzZSBoYXMgYW5vdGhlciBicmlsbGlhbnQgaWRlYT8/CgpPbiAxLzI0LzA3LCBt
YXRpbGRhIG1hdGlsZGEgPG1hdGlsZGFAZ3JhbmRlbC5kZT4gd3JvdGU6Cj4gSGkgQW50aG9ueSwK
Pgo+IGluIG15IG9waW5pb24gdGhlIGNvZGUgb2YgY3hfT3JhY2xlIGlzIG5vdCByZWFseSBjb3Jy
ZWN0IHdoZW4KPiBkZWFsaW5nIHdpdGggYSBjbGllbnQgc2lkZSBlbmNvZGluZyB3aGljaCBjYW4g
cmVzdWx0IGluIG1vcmUgdGhhbgo+IG9uZSBieXRlIHBlciBjaGFyYWN0ZXIuCj4KPiBJIGludmVz
dGVkIHNvbWUgaG91cnMgdG8gaW52ZXN0aWdhdCB5b3VyIGNvZGUgYW5kIE9yYWNsZSBPQ0kKPiBk
b2N1bWVudGF0aW9uIHRvIGdldCBjbG9zZXIgdG8gdGhlIHByb2JsZW0uIE5vdyBJIGhhdmUgc29t
ZQo+IGhpbnRzIGFuZCBJIGhvcGUgaXQgd2lsbCBoZWxwIHlvdSB0byBleHRlbmQgdGhlIGNvZGUu
Cj4KPiAxKSBTemVuYXJpbyB0byByZXByb2R1Y2UgdGhlIGVycm9yOgo+IERhdGFiYXNlIGhhcyB0
byBiZSBpbiBhIGNoYXJhY3RlciBzZXQsIHdoaWNoIGNhbiBnZW5lcmF0ZQo+IHR3byBieXRlIGVu
Y29kaW5ncyBpbiBVVEYtOC4gSW4gbW9zdCBjYXNlcyBMQVRJTjEgKGFrYSBXRThJU084ODU5UDEp
Cj4gaXMgb2suCj4KPiBDaGVjazoKPiBzZWxlY3QgdmFsdWUgZnJvbSBubHNfZGF0YWJhc2VfcGFy
YW1ldGVycyB3aGVyZSBwYXJhbWV0ZXIgPSAnTkxTX0NIQVJBQ1RFUlNFVCc7Cj4KPiAyKSBDcmVh
dGUgdGhlIGZvbGxvd2luZyB0YWJsZToKPiBjcmVhdGUgdGFibGUgdHN0ICgKPiAgICAgICAgZGF0
YSB2YXJjaGFyMigyKQo+ICkKPgo+IGluc2VydCBpbnRvIHRzdCB2YWx1ZXMgKCcxw4QnKTsKPgo+
IFRoc2kgc2hvdWxkIGZpdCBpbiB0aGUgdGFibGUsIGJlY2F1c2UgJ8OEJyBjYW4gYmUgcmVwcmVz
ZW50ZWQKPiBhcyBvbmUgYnl0ZSBpbiBMYXRpbjEuCj4KPiAzKSBUYWtlIHRoaXMgc2ltcGxlIHB5
dGhvbiBjb2RlOgo+IC0tLS0tLS0tLS0tLS04PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4g
IyEvdXNyL2Jpbi9weXRob24KPiAjIC0qLSBjb2Rpbmc6IHV0ZjggLSotCj4gaW1wb3J0IHN5cwo+
IGltcG9ydCBjeF9PcmFjbGUgYXMgZGJpCj4KPiBpZiBfX25hbWVfXyA9PSAnX19tYWluX18nOgo+
ICAgICBjb24gPSBkYmkuY29ubmVjdCgnc2NvdHQvdGlnZXJAdHd3cycpCj4gICAgIGN1ciA9IGNv
bi5jdXJzb3IoKQo+ICAgICBjdXIuZXhlY3V0ZSgnc2VsZWN0IGRhdGEgZnJvbSB0c3QnKQo+ICAg
ICByb3cgPSBjdXIuZmV0Y2hvbmUoKQo+ICAgICBwcmludCByb3cKPiAgICAgY3VyLmNsb3NlKCkK
PiAgICAgY29uLmNsb3NlKCkKPiAtLS0tLS0tLS0tLS0tODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQo+Cj4gNCkgTm93IHRoZSB0ZXN0czoKPiBleHBvcnQgTkxTX0xBTkc9R0VSTUFOX0dFUk1B
TlkuV0U4SVNPODg1OVAxCj4gIC4vdHN0LnB5Cj4gT3V0cHV0OiAoJzFceGM0JywpCj4gRXZlcnl0
aGluZyBpcyBmaW5lLCBiZWNhdXNlIG9uIHRoZSBjbGllbnQgc2lkZSBhIGJ1ZmZlciBvZiBsZW5n
dGggMiBpcwo+IGFsbG9jYXRlZCBhbmQgdGhlIE9DSS1kZWZpbmUgaXMgbGltaXRlZCB0byAyLgo+
IC0tLQo+IGV4cG9ydCBOTFNfTEFORz1HRVJNQU5fR0VSTUFOWS5VVEY4Cj4gIC4vdHN0LnB5Cj4g
T3V0cHV0Ogo+IFRyYWNlYmFjayAobW9zdCByZWNlbnQgY2FsbCBsYXN0KToKPiAgIEZpbGUgIi4v
dHN0LnB5IiwgbGluZSAxMCwgaW4gPwo+ICAgICByb3cgPSBjdXIuZmV0Y2hvbmUoKQo+IGN4X09y
YWNsZS5EYXRhYmFzZUVycm9yOiBjb2x1bW4gYXQgYXJyYXkgcG9zIDAgZmV0Y2hlZCB3aXRoIGVy
cm9yOiAxNDA2Cj4KPiBSZWFzb24gKGFzIGZhciBhcyBJIGNhbiBzZWUpOiAyIGNoYXJhY3RlcnMg
PSAyIGJ5dGVzIG9uIHRoZSBzZXJ2ZXIgc2lkZQo+IGFyZSBleHBhbmRlZCB0byAyIGNoYXJhY3Rl
cnMgPSAzIGJ5dGVzIG9uIGNsaWVudCBzaWRlLiBPQ0kgaXMgdGVsbGluZyB0aGF0Cj4gdGhlIGxl
bmd0aCAoZGIgc2lkZSkgb2YgdGhhdCB2YXJpYWJsZSBpcyAyLCBzbyAyIGJ5dGVzIGFyZSBhbGxv
Y2F0ZWQuCj4gRmV0Y2ggaXMgZG9uZSBpbiBhIDIgYnl0ZSBhcnJheSwgdGhhdCdzIHRvbyBzbWFs
bCA9PiBFcnJvciBtZXNzYWdlLgo+Cj4gKGNvbW1lbnQ6IElmIEkgdXNlIHZhcmNoYXIyKDEpLCBp
dCBzZWVtcyB0byB3b3JrIGJlY2F1c2UgeW91IGFkZAo+IHNvbWUgYnl0ZXMgaW4gYW55IGNhc2Ug
dG8gdGhlIGJ1ZmZlciBsZW5ndGguKQo+Cj4gNSkgSSBoYXZlIHNlZW4sIHRoYXQgeW91IG1hZGUg
dGhlIGFzc3VtcHRpb24sIHRoYXQgc3RyaW5ncyAobm90IGxvYnMpIGhhdmUKPiBhIG1heGltdW0g
bGVuZ3RoIG9mIDQwMDAuCj4gU3RyaW5nVmFyLmM6I2RlZmluZSBNQVhfU1RSSU5HX0xFTkdUSCAg
ICAgICAgICAgNDAwMAo+IEFzIGZhciBhcyBJIHVuZGVyc3Rvb2QgdGhlIE9yYWNsZSBkb2N1bWVu
dGF0aW9uLCB0aGlzIGlzIHRydWUgaW4gdGVybXMKPiBvZiBieXRlIHJlcHJlc2VudGF0aW9uIG9u
IHRoZSBkYiBzaWRlLiBUaGlzIGlzIG5vdCB0cnVlIG9uIHRoZSBjbGllbnQgc2lkZS4KPgo+IDYp
IEkgY2hhbmdlZCB5b3VyIGNvZGUgdG8gZ2V0IGEgc2ltcGxlIHRyYWNlIGZhY2lsaXR5LiBJZiB5
b3UgbGlrZSB0aGF0IGNvZGUKPiBjb250YWN0IG1lLiBJIGZvdW5kIHRoZSBmb2xsb3dpbmcgcGFy
YWdyYXBob2YgY29kZSBpbiBFbnZpcm9ubWVudC5jOgo+IC0tLS0tLS0tLS0tLS0tODwtLS0tLS0t
LS0tLS0tLS0tLS0tLS0KPiAjaWZkZWYgT0NJX05MU19DSEFSU0VUX01BWEJZVEVTWgo+ICAgICBz
dGF0dXMgPSBPQ0lObHNOdW1lcmljSW5mb0dldChlbnZpcm9ubWVudC0+aGFuZGxlLAo+ICAgICAg
ICAgICAgIGVudmlyb25tZW50LT5lcnJvckhhbmRsZSwgJmVudmlyb25tZW50LT5tYXhCeXRlc1Bl
ckNoYXJhY3RlciwKPiAgICAgICAgICAgICBPQ0lfTkxTX0NIQVJTRVRfTUFYQllURVNaKTsKPiAg
ICAgaWYgKEVudmlyb25tZW50X0NoZWNrRm9yRXJyb3IoZW52aXJvbm1lbnQsIHN0YXR1cywKPiAg
ICAgICAgICAgICAiRW52aXJvbm1lbnRfTmV3KCk6IGdldCBtYXggYnl0ZXMgcGVyIGNoYXJhY3Rl
ciIpIDwgMCkgewo+ICAgICAgICAgUHlfREVDUkVGKGVudmlyb25tZW50KTsKPiAgICAgICAgIHJl
dHVybiBOVUxMOwo+ICAgICB9Cj4KPiAgICAgLy8gYWNxdWlyZSB3aGV0aGVyIGNoYXJhY3RlciBz
ZXQgaXMgZml4ZWQgd2lkdGgKPiAgICAgc3RhdHVzID0gT0NJTmxzTnVtZXJpY0luZm9HZXQoZW52
aXJvbm1lbnQtPmhhbmRsZSwKPiAgICAgICAgICAgICBlbnZpcm9ubWVudC0+ZXJyb3JIYW5kbGUs
ICZlbnZpcm9ubWVudC0+Zml4ZWRXaWR0aCwKPiAgICAgICAgICAgICBPQ0lfTkxTX0NIQVJTRVRf
RklYRURXSURUSCk7Cj4gICAgIGlmIChFbnZpcm9ubWVudF9DaGVja0ZvckVycm9yKGVudmlyb25t
ZW50LCBzdGF0dXMsCj4gICAgICAgICAgICAgIkVudmlyb25tZW50X05ldygpOiBkZXRlcm1pbmUg
aWYgY2hhcnNldCBpcyBmaXhlZCB3aWR0aCIpIDwgMCkgewo+ICAgICAgICAgUHlfREVDUkVGKGVu
dmlyb25tZW50KTsKPiAgICAgICAgIHJldHVybiBOVUxMOwo+ICAgICB9Cj4gI2VuZGlmCj4gICAg
IHRyYWNlKCJFbnZpcm9ubWVudC5jOiBtYXhCeXRlc1BlckNoYXJhY3RlcjogJWRcbiIsIGVudmly
b25tZW50LT5tYXhCeXRlc1BlckMKPiBoYXJhY3Rlcik7ICAvLyB0aGF0cyBmcm9tIG1lCj4KPiAt
LS0tLS0tLS0tLS0tLTg8LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhpcyB2YWx1ZSB3YXMgMyB3
aGVuIEkgd29ya2VkIHdpdGggVVRGOAo+IGFuZCBvbmx5IDEgd2hlbiBJIGNob3NlIExBVElOMS4g
QXMgZmFyIGFzIEkgY2FuIHNlZSwgeW91Cj4gdXNlIHRoaXMgdmFsdWUgb25seSB3aXRoIGxvYnMu
IElzIHRoYXQgdHJ1ZT8KPiBOb3cgbXkgaGludDogQ291bGQgeW91IGFkanVzdCB0aGUgYWxsb2Nh
dGVkIGNsaWVudCBzaWRlIGJ1ZmZlciBsZW5ndGgKPiB3aXRoIG1heEJ5dGVzUGVyQ2hhcmFjdGVy
LiBBcyBJJ20gdG90YWxseSBuZXcgdG8geW91ciBjb2RlLAo+IEknbSBkb2luZyByZWFsbHkgaGFy
ZCBmaW5kaW5nIGFsbCBwbGFjZXMgYW5kIG5vdCBmb3JnZXR0aW5nIHNvbWUKPiBzaWRlIGVmZmVj
dHMuIFNvLCBJIGNhbid0IGdpdmUgeW91IGEgcGF0Y2guCj4gVW50aWwgbm93IEkgb25seSBjaGVj
a2VkIHRoZSBjb2RlIGZvciAiZGVmaW5lZCIgdmFyaWFibGVzLiBUaGUKPiBzYW1lIG11c3QgYmUg
dHJ1ZSBmb3IgImJpbmQiIHZhcmlhYmxlcy4KPiBTbywgSSdtIHByZXR0eSBzdXJlLCB0aGF0IHRo
ZSBmb2xsb3dpbmcgY29kZSBzbmlwcGV0IGlzIGFsc28gbm90IHJlYWxseQo+IHZhbGlkOgo+IC0t
LS0tLS0tLS0tLS0tLQo+ICAgICBlbHNlIGlmIChQeVN0cmluZ19DaGVjayh2YWx1ZSkpIHsKPiAg
ICAgICAgIHNpemUgPSBQeVN0cmluZ19HRVRfU0laRSh2YWx1ZSk7Cj4gICAgICAgICB0cmFjZSgi
VmFyaWFibGUuYzogc2l6ZTogJWRcbiIsIHNpemUpOwo+ICAgICAgICAgaWYgKHNpemUgPiBNQVhf
U1RSSU5HX0xFTkdUSCkKPiAgICAgICAgICAgICB2YXJUeXBlID0gJnZ0X0xvbmdTdHJpbmc7Cj4g
LS0tLS0tLS0tLS0tLS0tLS0tCj4gU3plbmFyaW8uIEkgaGF2ZSBhIGxpdHRlIHRhYmxlIGxpa2U6
Cj4gY3JlYXRlIHRhYmxlIHRzdCAoCj4gZGF0YSB2YXJjaGFyMig0MDAwKQo+ICkKPiBhbmQgYSBw
cm9ncmFtIGxpa2U6Cj4gLS0tLS0tLS0tLS0tLS0tLS0tCj4gIyEvdXNyL2Jpbi9weXRob24KPiAj
IC0qLSBjb2Rpbmc6IHV0ZjggLSotCj4gaW1wb3J0IHN5cwo+IGltcG9ydCBjeF9PcmFjbGUgYXMg
ZGJpCj4KPiBpZiBfX25hbWVfXyA9PSAnX19tYWluX18nOgo+ICAgICBjb24gPSBkYmkuY29ubmVj
dCgnc2NvdHQvdGlnZXJAdHd3cycpCj4gICAgIGN1ciA9IGNvbi5jdXJzb3IoKQo+ICAgICB2YWwg
PSAnw4QnICogNDAwMAo+ICAgICBwcmludCAnTGVuZ3RoOiAnLCBsZW4odmFsKQo+ICAgICBjb24u
YmVnaW4oKQo+ICAgICBjdXIuZXhlY3V0ZSgnaW5zZXJ0IGludG8gdHN0IHZhbHVlcyAoOnZhbCkn
LCAodmFsLCApKQo+ICAgICBjb24uY29tbWl0KCkKPiAgICAgY3VyLmNsb3NlKCkKPiAgICAgY29u
LmNsb3NlKCkKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBUaGUgbWVudGlvbmUg
YyBjb2RlIGFib3ZlIGFzc3VtZXMgaW4gYW55IGNhc2UgdGhhdAo+IEkgd2hhbnQgdG8gYmluZCBh
IGxvbmcgdmFyaWFibGUuIEludGVyZXN0aW5nbHksIGFzIGZhciBhcwo+IHRoaXMgbG9uZyB2YXJp
YWJsZSBpcyBzbWFsbGxlciBvciBlcXVhbCB0byB0aGUgc2l6ZSBvZiB0aGUKPiBkZXN0aW5hdGlv
biB2YXJjaGFyMi1jb2x1bW4gKGRiLXNpZGUsIHdoZW4gdXNlZCBVVEYtOAo+IDgwMDBieXRlPT40
MDAwYnl0ZSksIHRoZSBpbnNlcnQgaXMgZG9uZSBldmVuIGlmIGl0J3MgYm91bmQKPiAgYXMgbG9u
ZyB0eXBlLiBPcmNhbGUgc2VlbXMgIHRvIHBlcmZvcm0gYSB0cmFuc3BhcmFudCBjb252ZXJzaW9u
Lgo+ICBBcyBzb29uIGFzIHRoZSBkZXN0aW5hdGlvbiBpcyB0b28gc21hbGwgKExBVElOSTEsIDgw
MDBieXRlID0+IDgwMDBieXRlKQo+IEkgZ2V0IGFuIGVycm9yIGFib3V0IGxvbmcgdmFyaWFibGUg
YmluZGluZyB3aGF0IHdpbGwgY29uZnVzZSBzb21lb25lCj4gbm90IGtub3dpbmcgdGhhdCB5b3Ug
aW50ZXJuYWxseSBzd2l0Y2hlZCB0byBsb25nLWJpbmRpbmcuCj4gKFRyYWNlYmFjayAobW9zdCBy
ZWNlbnQgY2FsbCBsYXN0KToKPiAgIEZpbGUgIi4vaS5weSIsIGxpbmUgMTIsIGluID8KPiAgICAg
Y3VyLmV4ZWN1dGUoJ2luc2VydCBpbnRvIHRzdCB2YWx1ZXMgKDp2YWwpJywgKHZhbCwgKSkKPiBj
eF9PcmFjbGUuRGF0YWJhc2VFcnJvcjogT1JBLTAxNDYxOiBFaW4gTE9ORy1XZXJ0IGthbm4gbnVy
IHp1ciBFaW5m4paSZ3VuZyBpbiBlaW5lIExPTkctU3BhbHRlIGdlYnVuZGVuIHdlcmRlbgo+ICkK
Pgo+Cj4gNykgSW4gYW55IGNhc2UgdGhpcyBpcyBubyBjcml0aWNpc20gYWJvdXQgeW91ciB3b3Jr
LiBCdXQgSSB3b3VsZAo+IGxpa2UgdG8gd29yayB3aXRoIFVURi04IGVuY29kaW5nIG9uIGNsaWVu
dCBzaWRlIGFzIHRyYW5zcGFyZW50bHkKPiBhcyBJIGNhbiB3aXRoIExhdGluMS4gSSBsaWtlIGN4
X09yYWNsZSB3aXRoIHB5dGhvbiBtdWNoIG1vcmUKPiB0aGFuIHRoZSBQZXJsIERCSSBzdHVmZi4K
PiBBcyBsb25nIGFzIHRoZSBkaWZmZXJlbnQgc2VtYW50aWNzIG9mIGNoYXJhY3RlcnMgYW5kIGJ5
dGVzIGlzCj4gdGhlIHdheSBpdCBpcyBpbiBweXRob24gMi54IDwgcHl0aG9uIDMwMDAsIHRoZSBi
eXRlIGFycmF5cwo+IGRlbGl2ZXJlZCBieSBjeF9PcmFjbGUgdG8gcHl0aG9uIHNob3VsZCByZWZs
ZWN0IHRoZSBjb3JyZWN0Cj4gZW5jb2Rpbmcgb2YgdGhlIGRiLWNsaWVudC1zaWRlLgo+Cj4gSSBo
b3BlIHlvdSBjYW4gY29ycmVjdCB0aGlzIHByb2JsZW0uIEFzIHlvdSBjYW4gc2VlLCBJIGxpa2Ug
dG8gaW52ZXN0Cj4gYSBjb3VwbGUgb2YgdGltZSB0byBhc3Npc3Qgb3IgaGVscCB5b3UuCj4KPiBC
ZXN0IHJlZ2FyZHMKPiBBbmRyZWFzIE1vY2sKPgo+IFAuUy46IElnbm9yZSBhbGwgbWlzdGFrZXMg
aW4gdGhpcyBFbmdsaXNoIHRleHQuCj4KPgo+Cj4gNykgRm91bmQgdGhlIGZvbGxvd2luZyBkb2N1
bWVudGF0aW9uIG9mIGJ5dGUgZXhwYW5zaW9uIHdoaWxlIHVzaW5nCj4gdW5pY29kZS4gQXMgZmFy
IGFzIEkgY2FuIHNlZSwgdGhlIG1heGltdW0gZXhwYW5kZWQgYnVmZmVyIHNpemUgY2FuIGJlCj4g
NDAwMCAqIDQgaW4gd29yc3QgY2FzZS4KPiBodHRwOi8vd3d3LnN0YW5mb3JkLmVkdS9kZXB0L2l0
c3MvZG9jcy9vcmFjbGUvMTBnL3NlcnZlci4xMDEvYjEwNzQ5L2NoN3Byb2dydW5pY29kZS5odG0j
aTEwMDY0NTIKPgo+Cj4KPiA+Pj4gIkFudGhvbnkgVHVpbmluZ2EiIDxhbnRob255LnR1aW5pbmdh
QGdtYWlsLmNvbT4gMjMuMDEuMjAwNyAxODo1OSA+Pj4KPiBPbiAxLzIzLzA3LCBtYXRpbGRhIG1h
dGlsZGEgPG1hdGlsZGFAZ3JhbmRlbC5kZT4gd3JvdGU6Cj4KPiA+IEFzIGZhciBhcyBJIGtub3cs
IHNxbHBsdXMgZG9lcyByZWFsbHkgZG91YmxlIHRoZSBpbnRlcm5hbCBidWZmZXJzCj4gPiB0byBk
byB0aGUgY29tbXVuaWNhdGlvbiBmb3IgdGhlIGZvbGxvd2luZyBzemVuYXJpbzoKPiA+IERCIGNo
YXJhY3RlciBzZXQgaXMgTGF0aW4xID0+IEkgY2FuIHN0b3JlIGEgbWF4aW11bSBvZiA0MDAwCj4g
PiBHZXJtYW4gdW1sYXV0cyB0byB0aGUgYSBzdHJpbmcgY29sdW1uLiBUaGF0IHJlc3VsdHMgaW4g
ODAwMAo+ID4gYnl0ZXMgb24gdGhlIGNsaWVudCBzaWRlIGlmIHRoZXJlIGlzIGEgbXVsdGlieXRl
IGVuY29kaW5nIGVuYWJsZWQuCj4KPiBIbW0sIHRoYXQncyB3b3J0aCB0cnlpbmcsIEkgc3VwcG9z
ZS4gV291bGQgeW91IGJlIGFibGUgdG8gcHJvdmlkZSBhCj4gc21hbGwgdGVzdCBjYXNlIHRoYXQg
ZGVtb25zdHJhdGVzIHRoZSBwcm9ibGVtPyBTb21ldGhpbmcgdGhhdCBoYXMgNDAwMAo+IGNoYXJh
Y3RlcnMgaW4gaXQgd2hpY2ggd2lsbCBhY3R1YWxseSByZXN1bHQgaW4gY29uc2lkZXJhYmx5IGxh
cmdlcgo+IG51bWJlciBvZiBieXRlcy4gSSBjYW4gdGhlbiB0cnkgdGhhdCBhbmQgc2VlIGlmIHlv
dXIgYXNzdW1wdGlvbiBpcwo+IGNvcnJlY3QuIElmIGl0IGlzLCB0aGVuIHRoZSBtYXR0ZXIgaXMg
ZmFpcmx5IHNpbXBsZSB0byBhZGRyZXNzLgo+Cj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGFrZSBT
dXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElUCj4gSm9pbiBTb3Vy
Y2VGb3JnZS5uZXQncyBUZWNoc2F5IHBhbmVsIGFuZCB5b3UnbGwgZ2V0IHRoZSBjaGFuY2UgdG8g
c2hhcmUgeW91cgo+IG9waW5pb25zIG9uIElUICYgYnVzaW5lc3MgdG9waWNzIHRocm91Z2ggYnJp
ZWYgc3VydmV5cyAtIGFuZCBlYXJuIGNhc2gKPiBodHRwOi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1
bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBjeC1vcmFjbGUtdXNlcnMg
bWFpbGluZyBsaXN0Cj4gY3gtb3JhY2xlLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0
dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2N4LW9yYWNsZS11c2Vy
cwo+Cg==

Re: [cx-oracle-users] Reading CLOB output

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

Just execute an anonymous PL/SQL block as in the following:

cursor.execute("""
    begin
        dbms_metadata.set_transform_param( dbms_metadata.session_transform,
            'SQLTERMINATOR', TRUE);
        dbms_metadata.set_transform_param( dbms_metadata.session_transform,
            'PRETTY', TRUE);
        dbms_metadata.set_transform_param( dbms_metadata.session_transform,
            'SEGMENT_ATTRIBUTES', FALSE);
    end;""")

On 1/24/07, John Elliott <joh...@in...> wrote:
>
> Anthony Tuininga <anthony@...> writes:
>
> >
> > Sure, why not.
> >
> > import cx_Oracle
> >
> > connection = cx_Oracle.connect("user/pw@...")
> > cursor = connection.cursor()
> > clob = cursor.callfunc("dbms_metadata.get_ddl", cx_Oracle.CLOB,
> >         ("TABLE", "NODELINK"))
> > print "Value is:", clob.read()
> >
> > Is that simple enough?
> >
> > On Fri, 2004-03-19 at 13:03, Orr, Steve wrote:
> > > I'm using the cool 9i dbms_metadata package from SQLPlus but can't
> > > figure out how use it with cx_Oracle 4. Here's a clipping from a SQLPlus
> > > session:
> > > ---------------------------------------------------------------------
> > > SQL> SELECT dbms_metadata.get_ddl('TABLE','NODELINK') from dual;
> > >
> > >   CREATE TABLE "HYDRA"."NODELINK"
> > >    (    "ID" NUMBER,
> > >         "PARENTID" NUMBER,
> > >         "NODETEXT" VARCHAR2(252)
> > >    ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
> > >   STORAGE(INITIAL 65536 NEXT 65536 MINEXTENTS 1 MAXEXTENTS 2147483645
> > >   PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
> > >   TABLESPACE "USERS"
> > > ---------------------------------------------------------------------
> > >
> > > This returns the DDL for a database object as a CLOB. I've tried to use
> > > the cx_Oracle lob.read() function in Python but can't seem to figure it
> > > out. Can you provide some sample code on this?
> > >
> > >
> > > TIA!!
> > > Steve Orr
>
> How about the procedure calls to make the output pretty and introduce the sql
> terminator at the end.  How would I make the following calls using cx_oracle?
>
> -- set sql terminator so that semicolon and slash are inserted in
> -- the appropriate place.
> exec dbms_metadata.set_transform_param( dbms_metadata.session_transform,
> 'SQLTERMINATOR', TRUE);
>
> -- set Pretty paramter to format the output in an asthetically pleasing
> -- way
> exec dbms_metadata.set_transform_param( dbms_metadata.session_transform,
> 'PRETTY', TRUE);
>
> -- set Segment_attributes parameter to exclude the storage
> -- and other unwanted info.
> exec dbms_metadata.set_transform_param( dbms_metadata.session_transform,
> 'SEGMENT_ATTRIBUTES', FALSE);
>
> Thanks!  You have no idea how much time this is saving me!
>
> Thanks,
> John
>
>
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] Reading CLOB output

[John E. <joh...@in...>]

Anthony Tuininga <anthony@...> writes:

> 
> Sure, why not. 
> 
> import cx_Oracle
> 
> connection = cx_Oracle.connect("user/pw@...")
> cursor = connection.cursor()
> clob = cursor.callfunc("dbms_metadata.get_ddl", cx_Oracle.CLOB,
>         ("TABLE", "NODELINK"))
> print "Value is:", clob.read()
> 
> Is that simple enough? 
> 
> On Fri, 2004-03-19 at 13:03, Orr, Steve wrote:
> > I'm using the cool 9i dbms_metadata package from SQLPlus but can't
> > figure out how use it with cx_Oracle 4. Here's a clipping from a SQLPlus
> > session:
> > ---------------------------------------------------------------------
> > SQL> SELECT dbms_metadata.get_ddl('TABLE','NODELINK') from dual;
> > 
> >   CREATE TABLE "HYDRA"."NODELINK"
> >    (    "ID" NUMBER,
> >         "PARENTID" NUMBER,
> >         "NODETEXT" VARCHAR2(252)
> >    ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
> >   STORAGE(INITIAL 65536 NEXT 65536 MINEXTENTS 1 MAXEXTENTS 2147483645
> >   PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
> >   TABLESPACE "USERS"
> > ---------------------------------------------------------------------
> > 
> > This returns the DDL for a database object as a CLOB. I've tried to use
> > the cx_Oracle lob.read() function in Python but can't seem to figure it
> > out. Can you provide some sample code on this?
> > 
> > 
> > TIA!!
> > Steve Orr

How about the procedure calls to make the output pretty and introduce the sql
terminator at the end.  How would I make the following calls using cx_oracle? 

-- set sql terminator so that semicolon and slash are inserted in 
-- the appropriate place.
exec dbms_metadata.set_transform_param( dbms_metadata.session_transform,
'SQLTERMINATOR', TRUE);

-- set Pretty paramter to format the output in an asthetically pleasing 
-- way 
exec dbms_metadata.set_transform_param( dbms_metadata.session_transform,
'PRETTY', TRUE);

-- set Segment_attributes parameter to exclude the storage 
-- and other unwanted info.
exec dbms_metadata.set_transform_param( dbms_metadata.session_transform,
'SEGMENT_ATTRIBUTES', FALSE);

Thanks!  You have no idea how much time this is saving me!

Thanks,
John

Re: [cx-oracle-users] Problem with internal buffer sizes

[matilda m. <ma...@gr...>]

Hi Anthony,

in my opinion the code of cx_Oracle is not realy correct when
dealing with a client side encoding which can result in more than
one byte per character.=20

I invested some hours to investigat your code and Oracle OCI
documentation to get closer to the problem. Now I have some
hints and I hope it will help you to extend the code.

1) Szenario to reproduce the error:
Database has to be in a character set, which can generate
two byte encodings in UTF-8. In most cases LATIN1 (aka WE8ISO8859P1)
is ok.=20

Check:=20
select value from nls_database_parameters where parameter =3D 'NLS_CHARACTE=
RSET';

2) Create the following table:
create table tst (
       data varchar2(2)
)

insert into tst values ('1=C3=84');

Thsi should fit in the table, because '=C3=84' can be represented
as one byte in Latin1.

3) Take this simple python code:
-------------8<--------------------------
#!/usr/bin/python
# -*- coding: utf8 -*-
import sys
import cx_Oracle as dbi

if __name__ =3D=3D '__main__':
    con =3D dbi.connect('scott/tiger@twws')
    cur =3D con.cursor()
    cur.execute('select data from tst')
    row =3D cur.fetchone()
    print row
    cur.close()
    con.close()
-------------8<--------------------------

4) Now the tests:
export NLS_LANG=3DGERMAN_GERMANY.WE8ISO8859P1
 ./tst.py
Output: ('1\xc4',)
Everything is fine, because on the client side a buffer of length 2 is
allocated and the OCI-define is limited to 2.
---
export NLS_LANG=3DGERMAN_GERMANY.UTF8
 ./tst.py
Output:=20
Traceback (most recent call last):
  File "./tst.py", line 10, in ?
    row =3D cur.fetchone()
cx_Oracle.DatabaseError: column at array pos 0 fetched with error: 1406

Reason (as far as I can see): 2 characters =3D 2 bytes on the server side
are expanded to 2 characters =3D 3 bytes on client side. OCI is telling =
that
the length (db side) of that variable is 2, so 2 bytes are allocated.
Fetch is done in a 2 byte array, that's too small =3D> Error message.

(comment: If I use varchar2(1), it seems to work because you add
some bytes in any case to the buffer length.)

5) I have seen, that you made the assumption, that strings (not lobs) have
a maximum length of 4000.
StringVar.c:#define MAX_STRING_LENGTH           4000
As far as I understood the Oracle documentation, this is true in terms
of byte representation on the db side. This is not true on the client =
side.

6) I changed your code to get a simple trace facility. If you like that =
code
contact me. I found the following paragraphof code in Environment.c:
--------------8<---------------------
#ifdef OCI_NLS_CHARSET_MAXBYTESZ
    status =3D OCINlsNumericInfoGet(environment->handle,
            environment->errorHandle, &environment->maxBytesPerCharacter,
            OCI_NLS_CHARSET_MAXBYTESZ);
    if (Environment_CheckForError(environment, status,
            "Environment_New(): get max bytes per character") < 0) {
        Py_DECREF(environment);
        return NULL;
    }

    // acquire whether character set is fixed width
    status =3D OCINlsNumericInfoGet(environment->handle,
            environment->errorHandle, &environment->fixedWidth,
            OCI_NLS_CHARSET_FIXEDWIDTH);
    if (Environment_CheckForError(environment, status,
            "Environment_New(): determine if charset is fixed width") < 0) =
{
        Py_DECREF(environment);
        return NULL;
    }
#endif
    trace("Environment.c: maxBytesPerCharacter: %d\n", environment->maxByte=
sPerC
haracter);  // thats from me

--------------8<---------------------
This value was 3 when I worked with UTF8
and only 1 when I chose LATIN1. As far as I can see, you
use this value only with lobs. Is that true?
Now my hint: Could you adjust the allocated client side buffer length
with maxBytesPerCharacter. As I'm totally new to your code,
I'm doing really hard finding all places and not forgetting some
side effects. So, I can't give you a patch.
Until now I only checked the code for "defined" variables. The
same must be true for "bind" variables.=20
So, I'm pretty sure, that the following code snippet is also not really
valid:
---------------
    else if (PyString_Check(value)) {
        size =3D PyString_GET_SIZE(value);
        trace("Variable.c: size: %d\n", size);
        if (size > MAX_STRING_LENGTH)
            varType =3D &vt_LongString;
------------------
Szenario. I have a litte table like:
create table tst (
data varchar2(4000)
)
and a program like:
------------------
#!/usr/bin/python
# -*- coding: utf8 -*-
import sys
import cx_Oracle as dbi

if __name__ =3D=3D '__main__':
    con =3D dbi.connect('scott/tiger@twws')
    cur =3D con.cursor()
    val =3D '=C3=84' * 4000
    print 'Length: ', len(val)
    con.begin()
    cur.execute('insert into tst values (:val)', (val, ))
    con.commit()
    cur.close()
    con.close()
------------------------------
The mentione c code above assumes in any case that
I whant to bind a long variable. Interestingly, as far as
this long variable is smalller or equal to the size of the
destination varchar2-column (db-side, when used UTF-8
8000byte=3D>4000byte), the insert is done even if it's bound
 as long type. Orcale seems  to perform a transparant conversion.
 As soon as the destination is too small (LATINI1, 8000byte =3D> 8000byte)
I get an error about long variable binding what will confuse someone
not knowing that you internally switched to long-binding.
(Traceback (most recent call last):
  File "./i.py", line 12, in ?
    cur.execute('insert into tst values (:val)', (val, ))
cx_Oracle.DatabaseError: ORA-01461: Ein LONG-Wert kann nur zur Einf=E2=96=
=92gung in eine LONG-Spalte gebunden werden
)


7) In any case this is no criticism about your work. But I would
like to work with UTF-8 encoding on client side as transparently
as I can with Latin1. I like cx_Oracle with python much more
than the Perl DBI stuff.
As long as the different semantics of characters and bytes is
the way it is in python 2.x < python 3000, the byte arrays
delivered by cx_Oracle to python should reflect the correct
encoding of the db-client-side.=20

I hope you can correct this problem. As you can see, I like to invest
a couple of time to assist or help you.

Best regards
Andreas Mock

P.S.: Ignore all mistakes in this English text.



7) Found the following documentation of byte expansion while using
unicode. As far as I can see, the maximum expanded buffer size can be
4000 * 4 in worst case.
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10749/ch7prog=
runicode.htm#i1006452=20



>>> "Anthony Tuininga" <ant...@gm...> 23.01.2007 18:59 >>>
On 1/23/07, matilda matilda <ma...@gr...> wrote:

> As far as I know, sqlplus does really double the internal buffers
> to do the communication for the following szenario:
> DB character set is Latin1 =3D> I can store a maximum of 4000
> German umlauts to the a string column. That results in 8000
> bytes on the client side if there is a multibyte encoding enabled.

Hmm, that's worth trying, I suppose. Would you be able to provide a
small test case that demonstrates the problem? Something that has 4000
characters in it which will actually result in considerably larger
number of bytes. I can then try that and see if your assumption is
correct. If it is, then the matter is fairly simple to address.

Re: [cx-oracle-users] Problem with internal buffer sizes

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

On 1/23/07, matilda matilda <ma...@gr...> wrote:
> Hi Anthony,
>
> thanks for your fast answer. But I really get used to it.  :-))
> Probably you can remember me as I contacted you by private
> mail the first time. So, you see, I follow your abuse and mail to
> the mailing list.  :-))

You're welcome. And yes, thanks for posting to the mailing list for
the enlightenment (or confusion) of all. :-)

> How can I circumvent this problem? How can I even manually increase
> the buffers?

You cannot, unfortunately.

> As far as I know, sqlplus does really double the internal buffers
> to do the communication for the following szenario:
> DB character set is Latin1 => I can store a maximum of 4000
> German umlauts to the a string column. That results in 8000
> bytes on the client side if there is a multibyte encoding enabled.

Hmm, that's worth trying, I suppose. Would you be able to provide a
small test case that demonstrates the problem? Something that has 4000
characters in it which will actually result in considerably larger
number of bytes. I can then try that and see if your assumption is
correct. If it is, then the matter is fairly simple to address.

> How is the buffer size chosen for simple varchar2 columns in
> cx_Oracle?

The database provides that information. Unfortunately, Oracle is not
consistent in terms of whether bytes or characters are returned -- the
problem of having developed much of the code before Unicode was very
widespread. :-(

> Best regards
> Andreas Mock
>
>
>
> >>> "Anthony Tuininga" <ant...@gm...> 23.01.2007 17:24
> >>>
> Currently only LOBs use the environment's "maxBytesPerCharacter"
> specification. Unfortunately (as far as I know -- please correct me if
> I am wrong) varchar2 buffers are limited to 4000 bytes and are
> specified in bytes, not characters. So you may be able to get away
> with increasing the buffer size for small strings but for large
> strings bad things will start to happen. :-) I'm not sure if there is
> a reasonable way around this or not. If anyone cares to enlighten me
> I'd be happy to learn. Anyone??
>
> On 1/23/07, matilda matilda <ma...@gr...> wrote:
> > Hi all, hi Anthony,
> >
> > I have the following problem:
> >
> > The Oracle database I'm using has the internal encoding
> > WE8ISO8859P1. The frontend (shell, python) has the
> > default encoding UTF-8 (NLS_LANG=GERMAN_GERMANY.UTF8).
> > The Oracle client library is handling encoding convertion, BUT:
> > If I fetch a varchar2 (byte) column consisting of a character
> > that is encoded with two bytes in UTF-8, I get the following
> > error while fetching:
> >
> > cx_Oracle.DatabaseError: column at array pos 0 fetched with error:
> > 1406
> >
> > I think it's a problem with internal buffers of the bind variables.
> >
> > 1) What can I do to get rid of that without changing NLS_LANG?
> > 2) Is there or probably will there a way to transparently circumvent
> > this problem. (automatic claiming of bigger buffers).
> >
> > Thanks in advance
> > Andreas Mock
> >
> >
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > opinions on IT & business topics through brief surveys - and earn
> cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> > _______________________________________________
> > cx-oracle-users mailing list
> > cx-...@li...
> > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>