FreeTDS Development Group

["Luke Benstead" <kazade AT gmail.com>]

I'm using 0.64. The bug doesn't occur with 0.63 but I get a different bug
(duplicate rows returned when there is a warning) with 0.63 that is fixed in
0.64 :)

Setting a text-size does get rid of the crazy numbers, setting a text size
of 4000 in freetds.conf, sets the Server column size to 4000 and the client
one to 8000. Either way the bug still occurs.

The field is an ntext field that is empty (i.e a blank string, not NULL)

Luke.

On 31/05/07, James K. Lowden <jklowden AT freetds.org> wrote:
> Luke Benstead wrote:
> > When I run a select query on a blank text field. I get a segmentation
> > fault. Here is the last part of the log:
> >
> > token.c:526:processing result tokens.  marker is  81(TDS7_RESULT)
> > mem.c:519:tds_free_all_results()
> > token.c:1472:processing TDS7 result. set current_results to
> > tds->res_info token.c:3395:adjust_character_column_size:
> >     Server charset: UCS-2LE
> >     Server column_size: 2147483646
> >     Client charset: UTF-8
> >     Client column_size: -4
>
> Well, that's no good. We get -4 because UCS-2LE is 2 byte/char; UTF-8 is
> max 4 byte/char, so to convert we allow -- not very wisely, but still, the
> math --  2* 2147483646, which is 2 * (2^31 - 2) == 2^32 - 4.  As a signed
> integer (TDSCOLUMN::column_size is TDS_INT, a signed 32-bit integer),
> that's -4.  Bah.
>
> However CVS HEAD code checks for malloc failures in this case, and IIRC
> that code has been in place for some time.   What version of FreeTDS are
> you using?
>
> You say it's a "blank text field".  Does that mean a zero-length string,
> or a NULL?  Or something else?  Because the server is indicating it's a
> very big text field, two bytes shy of 2 GB, to be exact.
>
> Also, does it help if you set textsize to some reasonable value?
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds