FreeTDS Development Group

["Simon Talbot" <simont AT nse.co.uk>]

Yes, I thought exactly what you said, that the matching of character
sets is preventing the code which is erroneous being entered -- would
you like me to take my testing any further ?

Also I note that the current snapshot is about 10-15% slower than 0.61.2
with exactly the same application and data (produces identical results).
Is this to be expected at this stage of development, ie. Is there a lot
of debug floating around ?

Simon


-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Lowden, James K
Sent: 13 November 2003 19:27
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Problem with current snapshot


> From: Simon Talbot [mailto:simont AT nse.co.uk]
> Sent: November 13, 2003 12:09 PM
> 
> There could be a clue in here, by changing the client character set as
> you suggested to:
> 
> client charset = WINDOWS-1252
> 
> The WARNING messages were indeed removed -- BUT the main problem of:
> 
> DB-Library error:
>         iconv E2BIG: Error converting between character sets. Output
> buffer exhausted.
> Operating-system error:
>         OpenClient
> agrep: dblib.c:416: buffer_transfer_bound_data: Assertion `idx >= 0'
> failed.
> Aborted
> 
> WAS ALSO CURED

It's not that the messages themselves consume buffer space.  The
tds_iconv()
function is provided with a conversion buffer whose size is determined
by
the ratio of the character widths of the two encodings.  IOW, if the
client
is ISO-859-1 and the server is UCS-2, the character width ratio is 1:2.
Depending on whether we're reading or writing, the output buffer is 0.5
or 2
times the size of the input buffer.  

I suspect you circumnavigated a bug.  By matching your client charset to
the
server's, you would avoid engaging iconv(3) for CHAR data.  Instead,
tds_iconv() would just call memcpy(3).  If we have an off-by-one error,
the
copying logic might not trip on it, whereas iconv would be much more
sensitive.  

The log contains this odd remark:

>  tds_get_char_data: reading 250 on wire for 251 to client

Freddy: I think this message is bogus.  For non-text columns, that "251"
would be taken from curcol->column_cur_size.  When the message is
printed,
we don't yet know how many bytes will be written "to client".  We know
only
the curcol->column_size, the maximum the client can accept.  

I committed a fix that makes tds_get_char_data() quiet unless it detects
an
error.  

--jkl


-----------------------------------------
The information contained in this transmission may contain privileged
and confidential information and is intended only for the use of the
person(s) named above. If you are not the intended recipient, or an
employee or agent responsible for delivering this message to the
intended recipient, any review, dissemination, distribution or
duplication of this communication is strictly prohibited. If you are not
the intended recipient, please contact the sender immediately by reply
e-mail and destroy all copies of the original message. Please note that
we do not accept account orders and/or instructions by e-mail, and
therefore will not be responsible for carrying out such orders and/or
instructions.


_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds