a245fd604c
The problem was, that the function only considered the target XSQLVAR's sqltype, ignoring sqlsubtype. This led to a situation when assignment to NUMERIC or DECIMAL was treated as assignment to an underlying type, like SQL_LONG, performed without taking scale into account. Use ColumnTypeInfo and its getSdbcType, which provides the correct type, and add missing cases to setString. Fix setObjectWithInfo to make sure that the resulting number is correct. This also fixes export of NUMERIC/DECIMAL in HSQL migration. Previously it miscalculated the position of decimal separator, which accidentally went unnoticed in the existing unit test, because it was compensated by broken handling in Firebird SDBC for the specific numbers in the test. OResultSet::makeNumericString was also fixed; it didn't handle properly the case of zero fractional part: initial number 1200 with scale 2 was converted to a string "12.000" instead of expected "12.00". Change-Id: I5adac59737d21f91c782fe867d4827fb880fd62a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170812 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins |
||
|---|---|---|
| .. | ||
| complex/dbaccess | ||
| extras | ||
| python | ||
| unit | ||
| unoapi | ||