Uploaded image for project: 'MariaDB Connector/ODBC'
  1. MariaDB Connector/ODBC
  2. ODBC-21

operation executed by SQLExecDirect sometimes return error, which cause retrieving data failure

Details

    • Bug
    • Status: Closed (View Workflow)
    • Blocker
    • Resolution: Fixed
    • 2.0.0
    • None
    • None
    • None
    • ALU MGC8 product

    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

      Attachments

        Activity

          mikeca mikeca added a comment -

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

          mikeca mikeca added a comment - New log with 2.0.7m2 debug version odbc for your reference.

          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)

          Lawrin Lawrin Novitsky added a comment - 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)

          People

            Lawrin Lawrin Novitsky
            mikeca mikeca
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.