Re: "Data conversion resulted in overflow" with float constants
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 13 Jun 2013 10:59:42 -0430 arielCo <[email protected]> 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