[ODBC-276] Update of Binary data containing 0x00 does not work Created: 2020-04-03 Updated: 2020-04-06 Resolved: 2020-04-05 |
|
| Status: | Closed |
| Project: | MariaDB Connector/ODBC |
| Component/s: | General |
| Affects Version/s: | 3.1.6 |
| Fix Version/s: | 3.1.7 |
| Type: | Bug | Priority: | Major |
| Reporter: | Steve Millington | Assignee: | Lawrin Novitsky |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux x64 |
||
| Description |
|
I am doing a select for update and then SQLSetPos(SQL_UPDATE) on a particular row. Now, my table contains a column that is of type BINARY. The SQLSetPos(SQL_UPDATE) works fine unless the original data (as opposed to the updated data) contains a 0x00 byte. When it does contain such a byte, the SQLSetPos(SQL_UPDATE) returns success, but the row is not actually updated. I have create a Unit Test to demonstrate the issue, which I am putting here. The sequence of events is Create a table with a 6-byte BINARY column Source code of the test is here ... ; OK_SIMPLE_STMT(Stmt, "DROP TABLE IF EXISTS tmysql_setpos_bin"); rc = SQLTransact(NULL, Connection, SQL_COMMIT); CHECK_STMT_RC(Stmt, SQLFreeStmt(Stmt, SQL_CLOSE)); rc = SQLSetCursorName(Stmt, (SQLCHAR *)"venu",SQL_NTS); OK_SIMPLE_STMT(Stmt, "select * from tmysql_setpos_bin"); rc = SQLBindCol(Stmt,1,SQL_C_LONG,&nData,100,NULL); rc = SQLBindCol(Stmt,2,SQL_C_BINARY,szData,100,NULL); // Fetch Row 2 (That does not have a null) and update it diag(" pcrow:%d\n",pcrow); diag(" row2:%d,%s\n",nData,szData); rc = SQLSetPos(Stmt,1,SQL_POSITION,SQL_LOCK_NO_CHANGE); nData = 1000; rc = SQLSetPos(Stmt,1,SQL_UPDATE,SQL_LOCK_NO_CHANGE); rc = SQLRowCount(Stmt,&nlen); diag(" rows affected:%d\n",nlen); // Fetch Row 3 (That does have a null) and update it diag(" pcrow:%d\n",pcrow); diag(" row3:%d,%s\n",nData,szData); rc = SQLSetPos(Stmt,1,SQL_POSITION,SQL_LOCK_NO_CHANGE); nData = 1000; rc = SQLSetPos(Stmt,1,SQL_UPDATE,SQL_LOCK_NO_CHANGE); rc = SQLRowCount(Stmt,&nlen); diag(" rows affected:%d\n",nlen); rc = SQLFreeStmt(Stmt, SQL_UNBIND); rc = SQLFreeStmt(Stmt, SQL_CLOSE); OK_SIMPLE_STMT(Stmt, "select * from tmysql_setpos_bin"); myrowcount(Stmt); rc = SQLFreeStmt(Stmt, SQL_CLOSE); OK_SIMPLE_STMT(Stmt, "DELETE FROM tmysql_setpos_bin WHERE col2 = 'updat1'"); rc = SQLRowCount(Stmt,&nlen); rc = SQLFreeStmt(Stmt,SQL_CLOSE); OK_SIMPLE_STMT(Stmt, "DELETE FROM tmysql_setpos_bin WHERE col2 = 'updat2'"); rc = SQLRowCount(Stmt,&nlen); rc = SQLFreeStmt(Stmt,SQL_CLOSE); rc = SQLTransact(NULL,Connection,SQL_COMMIT); OK_SIMPLE_STMT(Stmt, "select * from tmysql_setpos_bin"); IS(5 == myrowcount(Stmt)); rc = SQLFreeStmt(Stmt,SQL_CLOSE); OK_SIMPLE_STMT(Stmt, "DROP TABLE IF EXISTS tmysql_setpos_bin"); return OK; |
| Comments |
| Comment by Steve Millington [ 2020-04-03 ] |
|
Note that the Jira has messed with the formatting of my code! The line starting "OK_SIMPLE_STMT(Stmt, "insert into tmysql_setpos_bin values(200," is . OK_SIMPLE_STMT(Stmt, "insert into tmysql_setpos_bin values(200,'My Followed by a null, expressed by 'back-slash back-slash zero' Followed by QL2')"); |
| Comment by Steve Millington [ 2020-04-03 ] |
|
Please also note that I have verified that the data received on the Fetch is correct (i.e. it contains the 0x00 byte) and that if the lengths parameter is specified the the correct value of 6 is returned, so the issue is something to do with the updating of the row, rather than with the fetching of the data. |
| Comment by Lawrin Novitsky [ 2020-04-03 ] |
|
Thank you for your report and especially for the testcase written using c/odbc tests framework. You didn't give me the opportunity to have any question |
| Comment by Lawrin Novitsky [ 2020-04-05 ] |
|
Pushed in the commit 835e52a873b5c35ef8af537e6223066a2c6742a2 |
| Comment by Steve Millington [ 2020-04-06 ] |
|
Thank you Lawrin for your swift turn-around of this. As you appreciate, the bug I raised was a small part of my larger operation, and I can confirm that with your fix in place, everything now works OK. I just now need to wait for a release so I can give it to my users |