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
a245fd604c