cx-oracle-users

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

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

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

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

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

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
>

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

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

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.  :-))

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

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.

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

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 

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
>

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

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

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

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

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
>