Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
3.1.12
-
None
Description
Taking SQL like this:
SELECT SUM( ROUND( field/ 2.2046, 1 ) ) FROM file |
and binding the result column as SQL_NUMERIC with a scale of 1 causes the subsequent fetch to fail with:
[ma-3.1.12][10.5.10-MariaDB]Numeric value out of range
|
debugging the driver it seems that the server considers that column as floating point and the error is being triggered here:
https://github.com/mariadb-corporation/mariadb-connector-odbc/blob/master/ma_statement.c#L1861
the value of buffer_length is 40 set internally by the driver based on the maximum length it expects for a numeric when written as a string while max_length is 300.
This happens with both MariaDB and MySQL as the server but only with the MariaDB ODBC driver - it doesn't happen with either database with the MySQL driver.
Attachments
Activity
It's a long time ago now that I opened this but having tried to dig back into it the issue was that the driver is using 40 internally as the space to allocate for the string form of a floating point result, which is probably reasonable, and the actual data returned was less than that but it was comparing to max_length which was very large and deciding the results had been truncated.
The good news is that having debugged things again now with 3.2.1 it seems that line was changed in b1fd282106d908b75e8763e85ece0262c609c760 and it now compares to the returned result length (just 7 in my test case) instead of max_length so no longer wrongly decides the value has been truncated.
Hi, thank you for the report and sorry for neglecting it for so long.
Mainly because I could not understand what's the problem here from first glance. Now I took some time to look deeply into it and made the test for it, and I am not sure I see a bug here. If length of that decimal is longer than SQL_NUMERIC can accommodate - than the error is correct. It can be longer than 38 digits + sigh + decimal point. If you are saying that meta_data returned by server is incorrect... But since you were getting this error - it looks like the length of number was indeed longer than 38 + 1 + 1.
I'm gonna close it for now as not a bug. If I misunderstood something and you are still interested in this bug - you can always re-open it.