[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: XML File LPexportBug737442.xml    

 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:

int test_store_result_1(MYSQL *mysql)
{
  MYSQL *stmt;
  int rc;
  char *query= "SELECT 'foo' FROM DUAL";
 
  stmt = mysql_stmt_init(mysql);
  FAIL_IF(!stmt, "stmt_init failed");
 
  rc= mysql_stmt_prepare(stmt, query, strlen(query));
  FAIL_IF(rc, mysql_stmt_error(stmt));
 
  rc= mysql_stmt_execute(stmt);
  FAIL_IF(rc, mysql_stmt_error(stmt));
 
  /* here we store the result set without binding, bind variables
     are required for fetch only */
  rc= mysql_stmt_store_result(stmt);   /* <------- this works ok */
  FAIL_IF(rc, mysql_stmt_error(stmt));
 
  mysql_stmt_close(stmt);
}
 
int test_store_result_2(MYSQL *mysql)
{
  MYSQL *stmt;
  MYSQL_BIND bind[1];
  int rc;
  char *query= "SELECT 'foo' FROM DUAL";
 
  stmt = mysql_stmt_init(mysql);
  FAIL_IF(!stmt, "stmt_init failed");
 
  rc= mysql_stmt_prepare(stmt, query, strlen(query));
  FAIL_IF(rc, mysql_stmt_error(stmt));
 
  rc= mysql_stmt_execute(stmt);
  FAIL_IF(rc, mysql_stmt_error(stmt));
 
  /* Geometry is not supported, mysql_bind_result should fail */
  memset(bind, 0, sizeof(bind));
  bind[0].buffer_type= MYSQL_TYPE_GEOMETRY;
 
  rc= mysql_stmt_bind_result(stmt, bind);
  FAIL_IF(!rc, "Expected error (unsupported buffer type)");
 
  /* We didn't bind as in test_store_result_1, but stmt_store_result
     fails, since it checks for stmt->lasterrno */
  rc= mysql_stmt_store_result(stmt);  /* <-----  this doesn't work */
  FAIL_IF(rc, mysql_stmt_error(stmt));
 
  mysql_stmt_close(stmt);
}



 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.

Generated at Thu Feb 08 06:30:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.