On Thu, Mar 23, 2006 at 04:35:25PM -0000, Brian Fenton wrote:

> Do people think it's ok to proceed with CharExpansion=2. I'm cautious

Yes, it looks pretty safe to me.  Certainly safe enough to go ahead
and try it!

On the nsoracle CVS Head (and presumably in all earlier versions as
well), the Ns_OracleBindRow() code in nsoracle.c is simply multiplying
some buffer size by that CharExpansion integer.  From the code I think
this is one buffer per column in the result set.  It seems to be for
holding either just the column names, or the data for each column - I
think just the column names but I'm not entirely clear on that.

So, you might allocate twice as much memory as you really need, but
that's the only obvious downside.  It's probably a small amount of
memory anyway.

> http://cvs.sourceforge.net/viewcvs.py/aolserver/nsoracle/Attic/ora8.c?rev=1.11
>  
> says:
> "CharExpansion
>       integer defaulting to 1.
>       factor by which byte representation of character
>       strings can expand when fetched from the database.
>       Should only be necessary to set this if your Oracle
>       is not using UTF-8, in which case a value of 2 should
>       work for any ISO-8859 character set.b"

UTF-8 has multibyte characters, ASCII and the ISO-8859-* character
sets do not.  So you need more a larger byte buffer when processsing
UTF-8.  So perhaps the above desription is simply backwards.

On the other hand, perhaps when Oracle is actually using UTF-8
internally, its OCI functions reports data sizes in bytes which
already take into account the fact that UTF-8 can be multibyte and
thus take more space.  And thus it's when converting from Oracle
ISO-8859-* to Tcl UTF-8 that you might need more space than Oracle
claims that you do.  If that's the case, then the docs above would be
correct.  Dunno.

The very existence of CharExpansion looks like an ugly hack, btw.  But
it's also a very simple implementation, so I'd say it's only MILDLY
ugly.  :)

-- 
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to