Bug #98060 | ODBC v8.0.11 works, v0.8.12+ no rows, v8.0.16+ zero values | ||
---|---|---|---|
Submitted: | 23 Dec 2019 20:12 | Modified: | 9 Jan 2020 8:49 |
Reporter: | Sander Bouwhuis | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | Connector / ODBC | Severity: | S1 (Critical) |
Version: | v8.0.12+, 8.0.18 | OS: | Windows (x64) |
Assigned to: | CPU Architecture: | x86 |
[23 Dec 2019 20:12]
Sander Bouwhuis
[23 Dec 2019 20:15]
Sander Bouwhuis
It doesn't matter whether I set the parameter to 'Everything' or to 'Burpjes'. Both give the wrong results as mentioned above.
[24 Dec 2019 8:02]
MySQL Verification Team
Hello Sander Bouwhuis, Thank you for the report and feedback. regards, Umesh
[24 Dec 2019 8:27]
Sander Bouwhuis
I did some more tests with the v5.3.x series: v5.3.8 : works -> returns 1 row with User_settings_profile_id = 2 v5.3.9 : works -> returns 1 row with User_settings_profile_id = 2 v5.3.10 : works -> returns 1 row with User_settings_profile_id = 2 v5.3.11 : fails -> returns 0 rows v5.3.12 : fails -> returns 0 rows v5.3.13 : fails -> returns 1 row with User_settings_profile_id = 0 v5.3.14 : fails -> returns 1 row with User_settings_profile_id = 0 So, clearly you people had a regression in v5.3.11 and then a bugged fix in v5.3.13. Seeing both the v8.x branch and the v5.3.x branch go from working, to regression, to bugged fix I'd say this is a BIG problem. A database that gives WRONG data is DEADLY. It's nearly impossible to check which queries return the correct result and which don't. YOU ARE SCARING ME! !!!HELP HELP HELP!!!
[9 Jan 2020 2:33]
Bogdan Degtyariov
Dear Sander, we are sorry to hear about the issues you are having with ODBC. There is a temporary workaround to this problem, which is to use the client-side prepared statements, which means not using the server-side prepared statements (SSPC). This can be done by adding NO_SSPS=0; to the connection string or by setting the following option from the GUI dialog: Detalis >> Misc >> [x] Prepare statements on the client. Meanwhile we are working on fixing this with SSPS enabled. Thanks for your patience.
[9 Jan 2020 6:34]
Bogdan Degtyariov
Posted by developer: This bug is a combination of two problems already reported in the following two bugs: Bug #29467224 STORED PROCEDURE CALL VIA ADO DB AND ODBC CONNECTOR RETURNS RESULTSET OF 1 ROW Bug #30428851 Prepared Statements when using ODBC / ClassicASP always return 0 for INT values The problem is confirmed in the version MySQL ODBC 8.0.18. It happened for prepared statements putting the wrong value of numerical parameters in parametrized queries. The fix was pushed to the source tree for the above mentioned bugs.
[9 Jan 2020 6:47]
Sander Bouwhuis
Thanks for the response! Will this fix be in the upcoming MySQL ODBC v8.0.19? I REALLY want it to help my customers. If I revert to an older ODBC driver (like v8.0.11), it may contain other bugs that were fixed in v8.0.12 through v8.0.18.
[9 Jan 2020 8:48]
Rafal Somla
Posted by developer: Duplicate of Bug #29467224 and Bug #30428851, both fixed in 8.0.19.
[9 Jan 2020 9:00]
MySQL Verification Team
External/Public bug# of Rafal's above note. Bug #94623 & Bug #97191
[9 Jan 2020 9:30]
Bogdan Degtyariov
C test case that passes with the new ODBC driver version and fails with 8.0.12 - 8.0.18
Attachment: bug30697308.c (text/x-csrc), 4.67 KiB.