[ODBC-21] operation executed by SQLExecDirect sometimes return error, which cause retrieving data failure Created: 2015-05-04  Updated: 2015-05-30  Resolved: 2015-05-13

Status: Closed
Project: MariaDB Connector/ODBC
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: mikeca Assignee: Lawrin Novitsky
Resolution: Fixed Votes: 0
Labels: None
Environment:

ALU MGC8 product

Attachments: Text File log.txt    

 Description   

Our tester found the issue again. Here is the description. If the same data is fetched repeatedly via our command interface, it failed sometimes. Below is our log for your reference. And odbc log is also attached.

The log of successful data fetch:

00001(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: DB command allowed for table 4505
00002(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: START
00003(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - tableIndex(4506)
00003(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - Id(154)
00004(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - TableName(MGCPRFLMEGACO)
00005(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - rowSize(156)
00006(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - numCols(30)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - numKeys(1)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - logLevel(31)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - encryptIndex(-1)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: INFO - key MGCOPRFLID : pres(0)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - Primary Key Count(0)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - stmtLen(35)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.078 13310: getApi: DEBUG - stmt(SELECT count FROM MGCPRFLMEGACO )
00001(00672),00000(00000) 0x00000001 04-26 04:21:22.079 13310: getApi: INFO - count(1)

The log of failing to get data immediately after the successful one above:

00001(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: DB command allowed for table 4505
00002(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: START
00003(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - tableIndex(4506)
00003(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - Id(154)
00004(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - TableName(MGCPRFLMEGACO)
00005(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - rowSize(156)
00006(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - numCols(30)
00007(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - numKeys(1)
00008(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - logLevel(31)
00008(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - encryptIndex(-1)
00009(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: INFO - key MGCOPRFLID : pres(0)
00010(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - Primary Key Count(0)
00011(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - stmtLen(35)
00012(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi: DEBUG - stmt(SELECT count FROM MGCPRFLMEGACO )
00001(00672),00000(00000) 0x00000001 04-26 04:21:22.478 13312: getApi(../src/GetDBApi.c:683): ERROR - SQLExecDirect Failed - Unknown prepared statement handler (113) given to mysqld_stmt_reset ODBC Error/Warning = HY000, MySQL Error/Warning = 1243, ConnStr = socket=/opt/MySql/mysqld/mysql.sock;uid=PERM_DBP_SOFT;database=SoftSwitch;OPTIONS=4;, plx Caller's plxThreadID = 13312 & plxThreadName = dbp:Pool

 Comments   
Comment by mikeca [ 2015-05-08 ]

New log with 2.0.7m2 debug version odbc for your reference.

Comment by Lawrin Novitsky [ 2015-05-13 ]

The issue can be recreated with following testcase
ODBC_TEST(t_mysqld_stmt_reset)
{
OK_SIMPLE_STMT(Stmt, "drop table if exists t_reset");
OK_SIMPLE_STMT(Stmt, "create table t_reset (a int)");
OK_SIMPLE_STMT(Stmt, "INSERT INTO t_reset(a) VALUES (1),(2),(3)");

/* Succesful query deploying PS */
OK_SIMPLE_STMT(Stmt, "SELECT count FROM t_reset");
CHECK_STMT_RC(Stmt,SQLFetch(Stmt));
is_num(my_fetch_int(Stmt, 1), 3);
CHECK_STMT_RC(Stmt, SQLFreeStmt(Stmt, SQL_CLOSE));

/* Unsuccessful quer */
EXPECT_STMT(Stmt, SQLExecDirect(Stmt, "SELECT count FROM t_reset_nonexistent", SQL_NTS), SQL_ERROR);
CHECK_STMT_RC(Stmt, SQLFreeStmt(Stmt, SQL_CLOSE));

/* Successful directly executed query */
OK_SIMPLE_STMT(Stmt, "delete from t_reset where a=2");
CHECK_STMT_RC(Stmt, SQLFreeStmt(Stmt, SQL_CLOSE));

/* And now successful query again */
OK_SIMPLE_STMT(Stmt, "SELECT count FROM t_reset");
CHECK_STMT_RC(Stmt,SQLFetch(Stmt));
is_num(my_fetch_int(Stmt, 1), 2);

CHECK_STMT_RC(Stmt, SQLFreeStmt(Stmt, SQL_CLOSE));

OK_SIMPLE_STMT(Stmt, "drop table if exists t_reset");
return OK;
}

The fix(or rathat work-around), as the bug seemingly resides in c/c or in the server.
1.0.x version was also affected
The fix and the testcase have been pushed to both branches(23f13a8d233c821682f97b29c2fd87e781cfcb7c)

Generated at Thu Feb 08 03:25:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.