[freetds] "Data conversion resulted in overflow" with float constants

James K. Lowden jklowden at freetds.org
Thu Jun 13 18:36:28 EDT 2013


On Thu, 13 Jun 2013 10:59:42 -0430
arielCo <arielco at gmail.com> wrote:

> dblib.c:3142:dbdatlen() type = 108, len= 35
> dblib.c:2217:dbconvert(1001166d0, SYBNUMERIC, 1001146e0, 35, SYBCHAR,
> 100109b40, 1)
> dblib.c:2349:dbconvert() calling tds_convert
> dblib.c:2352:dbconvert() called tds_convert returned 3
> dblib.c:2455:dbconvert() outputting 3 bytes character data destlen = 1
> dblib.c:7929:dbperror(1001166d0, 20049, 0)
> dblib.c:7981:20049: "Data conversion resulted in overflow"

Right, that's a bug in fisql, one I actually vaguely recall. 

tdsconvert() in effect takes two 3-tuples of {type, buffer ponter, and
length}, one input and one output.  The output length is the last
parameter and, as you see above, the value provided is 1.  dbconvert()
detects that the required size, 3, is less than the size of the buffer
provided by the application, 1, and returns an overflow error.  

The mistake in fisql is in src/apps/fisql/fisql.c line 196, where
get_printable_column_size() sizes its character buffer according to
the larger of 

1.  column size, dbcollen()
2.  length of the column *name*, strlen(dbcolname())  

Column size as a string buffer size is inappropriate for integer
types.  It's usually OK because the column name is big enough.  You
will find you can convert any literal you like, as long as you give it
the alias "supercalifragilistic".  

The right thing to do -- your mission, should you choose to accept it
-- is to use tdswillconvert() instead to determine the size.  

HTH.  

--jkl


More information about the FreeTDS mailing list