Ubuntu Linux, test compiled from source, run against MySQL 5.7.19

The patched tests fail of course, since you can't use mysql_stmt_seek with an unbuffered result set.
If you want to use mysql_stmt_fetch_column with an unbuffered result set, you have to fetch data first:

mysql_stmt_execute(stmt);

mysql_stmt_fetch(stmt); /* load first row into buffer */

mysql_stmt_fetch_column(stmt, ....

Please also note, that MySQL Connector/C will fail with same errors (both tests are part of mysql_client_test.c)

  DBUG_ENTER("mysql_stmt_fetch_column");

  if ((int) stmt->state < (int) MYSQL_STMT_FETCH_DONE)

  {

    set_stmt_error(stmt, CR_NO_DATA, unknown_sqlstate, NULL);

    DBUG_RETURN(1);

  }

I'm pretty sure this is what I had done before - execute, fetch, fetch column. This worked for all fixed-size data types, but consistently failed for varchar and blob, and only succeeded after I changed the code to execute, store, fetch, fetch column. I spent the better part of yesterday isolating the problem.

The test cases might not reflect the problem I was experiencing. I'll follow up with more information, but perhaps you can replicate?

Yes, it's reproducable.- if mysql_stmt_bind_result was not called before, the internal stmt->bind structure has incorrect length and null values.

Awesome, thanks for taking another look!

connector_c_2.3 branch:
commit a028307e4182eb7f07c14e5cf7f32b358a3ccd1c

master_branch (3.0.3)
commit 17110fb9298fb328759bef287ceb72f97cc81a04

Wow! Thanks again for the fast resolution.

Is there a way to retrieve the connector version in a robust way (e.g. in my `configure` script), so that I can keep the workaround for old versions?

You can use

$ bin/mariadb_config 

Copyright 2011-2017 MariaDB Corporation AB

Get compiler flags for using the MariaDB Connector/C.

Usage: mariadb_config/mariadb_config [OPTIONS]

  --cflags        [-I/usr/local/include/mariadb -I/usr/local/include/mariadb/mysql]

  --include       [-I/usr/local/include/mariadb -I/usr/local/include/mariadb/mysql]

  --libs          [-L/usr/local/lib/mariadb/ -lmariadb -lpthread -ldl -lm -lssl -lcrypto]

  --libs_r        [-L/usr/local/lib/mariadb/ -lmariadb -lpthread -ldl -lm -lssl -lcrypto]

  --libs_sys      [-lpthread -ldl -lm -lssl -lcrypto]

  --version       [10.2.9]

  --socket        [/tmp/mysql.sock]

  --port          [3306]

  --plugindir     [/usr/local/lib/mariadb/plugin]

  --tlsinfo       [OpenSSL 1.1.1]

Thanks. But how does the 10.2.9 returned by `mariadb_config` correspond to the C connector version (2.3.x or 3.0.x)?

I'd like to request clarification:

• Is there a workaround for this problem? Unfortunately, storing the entire result at the client seems to have other problems, see https://github.com/rstats-db/RMariaDB/issues/60 and https://github.com/rstats-db/RMariaDB/issues/61.
• Which versions are affected, only 2.3.3 or several versions prior to 2.3.3? And for version 3, only 3.0.2 or also 3.0.1 and 3.0.0? Also, I can't seem to replicate this problem when building my library against libmariadb-dev 2.3.2-2 on Ubuntu – why?
• How do I reliably determine from the output of `mariadb_config` if the installed version is affected by the problem?

Thanks.

Is it at all possible this issue is back in MariaDB Connector/C 3.0.5? We recently updated and have customers reporting this error being emitted:
stmt fetch (oversized) column failed: 2051:

Code that generated this error is here:
https://github.com/Monetra/mstdlib/blob/master/sql/mysql/mstdlib_sql_mysql.c#L856

Brad,

I don't think this is related to the original issue (wrong length calculation). The CR_NO_DATA error (2051) is immediately returned at the beginning of the function mysql_stmt_fetch_column():

if (stmt->state < MYSQL_STMT_USER_FETCHING || column >= stmt->field_count ||

      stmt->state == MYSQL_STMT_FETCH_DONE)  {

    SET_CLIENT_STMT_ERROR(stmt, CR_NO_DATA, SQLSTATE_UNKNOWN, 0);

    return(1);

  }

It would be helpful to start a debug session and check which of the conditions above will fail.

Unfortunately I don't have access to the customer's systems and I'm not able to reproduce myself. I'm testing on Percona XtraDB Cluster 5.7.22, but the customer is on the official Oracle Enterprise MySQL 5.6.40. Reverting back to the 3.0.3 release resolved the customer issue.

I can say we do reuse statement handles, so it could be related to CONC-344 possibly somehow.

If we can figure out how to reproduce, I'll open another ticket.

Hi, it is easy to repro with connector 3.0.7 and MySQL 5.7.22

Just fetch any table with a varchar binding with `buffer_length == 0`. Resize the buffer and update length after `mysql_stmt_fetch` and `mysql_stmt_fetch_column` will always returns `CR_NO_DATA`.

Regards,
Mauro.

It was fixed in connector 3.0.3, but at 3.0.4 or later (I've also checked versions 3.0.7 and 3.0.8), the issue reoccurs. As Mauro said, this issue can easily be reproduced.

As a workaround set MYSQL_REPORT_DATA_TRUNCATION option to zero in the connection options. Checked with source code.