[MDEV-683] LP:737442 - mysql_stmt_store_result() does not work after an unsuccessfull call to mysql_stmt_bind_result() Created: 2011-03-18 Updated: 2017-11-05 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 10.0.1, 5.5.30, 5.1.67, 5.2.14, 5.3.12 |
| Fix Version/s: | 10.2 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Philip Stoev (Inactive) | Assignee: | Georg Richter |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Launchpad, upstream | ||
| Attachments: |
|
| Description |
|
A mysql_stmt_bind_result() call that results in an error prevents future mysql_stmt_store_result() from working since stmt->lasterrno is now set. Example:
|
| Comments |
| Comment by Rasmus Johansson (Inactive) [ 2011-10-28 ] |
|
Launchpad bug id: 737442 |
| Comment by Elena Stepanova [ 2013-03-29 ] |
|
Reproducible everywhere, but as Georg discovered, this behavior is explicitly covered by test_pure_coverage. so maybe it's intended. It would be interesting to find out why, and, more importantly, how an application is supposed to deal with a "broken" statement handle. Assigning to Georg since he's looking into it. If it turns out to be not a bug, it should be closed as such. |
| Comment by Georg Richter [ 2013-04-02 ] |
|
The current error handling for the prepared statements is kind of suboptimal: The pure_coverage test was introduced when more server side cursor types were supported (these options are disabled since 5.1). The test case from Philip shows a "dead end road", since there is no way to reset an error without resetting the statement handle. I can see two possible solutions: 1) Dirty: check the error number in mysql_stmt_store_result and continue 2) Allow to unbind a result set by specifying a NULL parameter in mysql_stmt_bind_result. |