https://bugs.documentfoundation.org/show_bug.cgi?id=156530
--- Comment #16 from Lionel Elie Mamane <[email protected]> --- (In reply to Lionel Elie Mamane from comment #14) > So we need to "understand" whether that is really > an integer or the integer storage for a NUMERIC or DECIMAL, but I don't > immediately see how one determines that. Hmm... Try something like that: case SQL_LONG: { short sqlscale = pVar->sqlscale; // move the decimal in the string by -sqlscale // and AFTER THAT take the integer part of it // e.g. if the string is "123.456789" and sqlscale is -1 // then int32Value should be "1234" // if the string is "123.456789" and sqlscale is -2 // then int32Value should be.... maybe "12345" // or maybe "12346" because we need to use rounding, not truncation? // yes, I think do rounding, not truncation setInt(nParameterIndex, int32Value); break; } and do the same for the other cases: SQL_SHORT, SQL_INT64, etc. Additionally this code is fundamentally wrong, at least placed where it is. 200 if (str.getLength() > pVar->sqllen) 201 str = str.copy(0, pVar->sqllen); It is not linked to "believing we need an integer value", it is just a coincidence; an SQL_LONG takes four bytes AND IN THIS PARTICULAR EXAMPLE, four CHARACTERS OF THE STRING takes the integer value plus the dot, BUT THAT'S JUST A COINCIDENCE. This code should be only in the codepath of the cases SQL_VARYING, SQL_TEXT, SQL_BLOB, and NOT in the cases SQL_INT/LONG/FLOAT/etc. It would be nice to have a unittest for all that. It would be pretty simple, just have a firebird database with columns of different types (VARCHAR, NUMERIC, DECIMAL, INTEGER, FLOAT, ...) and try to set values of these columns by setString(), then read the value from the database and check it is the correct one depending on the string. -- You are receiving this mail because: You are the assignee for the bug.
