Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
2.0.11
-
None
-
None
-
Linux x86_64 CentOS 6.5
Description
Calling SQLTables fails with an error on invalid string error. It seems that it's the TABLE_COMMENT / REMARK column that fails in MADB_ConvertAnsi2Unicode. This has been tested and reproduces with MariaDB 10.2.1 and with MariaDB ColumnStore 1.0.2, but not on MariaDB 10.1.16. Looking at the ODBC Driver sources, I see that the REMARK column is sometimes mapped to NULL and sometimes to TABLE_COMMENT. As the ODBC driver is really important for MariaDB ColumnStore, this is significant. Running Business Objects on MariaDB CS is, due to this issue, not possible at this point in time.The following code illustrates the issue.
#include <stdio.h>
|
#include <sqlext.h>
|
|
|
int main(int argc, char *argv[]) |
{
|
SQLHANDLE hEnv, hConn, hStmt;
|
SQLRETURN nRet;
|
SQLCHAR szErrMsg[256];
|
SQLCHAR szErrState[5];
|
SQLINTEGER nErrNative;
|
SQLSMALLINT nErrMsgLen;
|
SQLSMALLINT nDiagRec;
|
SQLSMALLINT nCols;
|
SQLCHAR szCatalog[64];
|
SQLLEN iCatalog;
|
SQLCHAR szSchema[64];
|
SQLLEN iSchema;
|
SQLCHAR szName[64];
|
SQLLEN iName;
|
SQLCHAR szType[64];
|
SQLLEN iType;
|
SQLCHAR szRemarks[3096];
|
SQLLEN iRemarks;
|
|
|
if(argc < 3) |
{
|
fprintf(stderr, "Usage: %s <DSN> <user> <password>\n", argv[0]); |
return 1; |
}
|
|
|
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hEnv);
|
SQLSetEnvAttr(hEnv, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0); |
SQLAllocHandle(SQL_HANDLE_DBC, hEnv, &hConn);
|
if((nRet = SQLConnect(hConn, argv[1], SQL_NTS, argv[2], SQL_NTS, argv[3], SQL_NTS)) != SQL_SUCCESS) |
{
|
SQLError(hEnv, hConn, SQL_NULL_HSTMT, NULL, NULL, szErrMsg, sizeof(szErrMsg), NULL); |
fprintf(stderr, "Error in connecting to MariaDB:\n%s\n", szErrMsg); |
|
|
return 1; |
}
|
|
|
SQLAllocHandle(SQL_HANDLE_STMT, hConn, &hStmt);
|
SQLBindCol(hStmt, 1, SQL_C_WCHAR, szCatalog, sizeof(szCatalog), &iCatalog); |
SQLBindCol(hStmt, 2, SQL_C_WCHAR, szSchema, sizeof(szSchema), &iSchema); |
SQLBindCol(hStmt, 3, SQL_C_WCHAR, szName, sizeof(szName), &iName); |
SQLBindCol(hStmt, 4, SQL_C_WCHAR, szType, sizeof(szType), &iType); |
SQLBindCol(hStmt, 5, SQL_C_WCHAR, szRemarks, sizeof(szRemarks), &iRemarks); |
if((nRet = SQLTables(hStmt, "test", SQL_NTS, NULL, SQL_NTS, NULL, SQL_NTS, NULL, SQL_NTS)) != SQL_SUCCESS) |
{
|
SQLError(hEnv, hConn, hStmt, NULL, NULL, szErrMsg, sizeof(szErrMsg), NULL); |
fprintf(stderr, "Error in SQLTables:\n%s\n", szErrMsg); |
|
|
return 1; |
}
|
SQLNumResultCols(hStmt, &nCols);
|
printf("Cols: %d\n", nCols); |
while((nRet = SQLFetch(hStmt)) == SQL_SUCCESS) |
{
|
}
|
if(nRet != SQL_NO_DATA) |
{
|
for(nDiagRec = 1; ; nDiagRec++) |
{
|
if(SQLGetDiagRec(SQL_HANDLE_STMT, hStmt, nDiagRec, szErrState, &nErrNative, |
szErrMsg, sizeof(szErrMsg), &nErrMsgLen) != SQL_SUCCESS) |
break; |
fprintf(stderr, "Error %d in SQLFetch %d %.5s\n%.*s\n", nDiagRec, nErrNative, |
szErrState, nErrMsgLen, szErrMsg);
|
}
|
|
|
return 1; |
}
|
SQLFreeHandle(SQL_HANDLE_STMT, hStmt);
|
SQLFreeHandle(SQL_HANDLE_DBC, hConn);
|
SQLFreeHandle(SQL_HANDLE_ENV, hEnv);
|
|
|
return 0; |
}
|
Attachments
Activity
Good. There sure seems to be something odd with this in that it appears sometimes and sometimes not. Might it be an issue with C/C even? I have done a fair amount of testing with this and it seems that mysql_stmt_bind_result returns odd data for the TABLE_COMMENT column.
Well, my first intention was to answer "no, that is own c/odbc problem", but then had decided to leave some chances for c/c as well 
will see.
You correctly pointed to the place in c/odbc code there the error occurs. There is one more issue with same error, but in different circumstances, and that I could not re-create yet. So, your bug report came just in time.
Refined description is "If application binds column as SQL_C_WCHAR, connector would return error on fetch operation if that column contained empty string". The patch and testcase have been pushed. Next release is 2.0.12. Not sure if SQLGetData was affected, but testcase covers it, too. Patch also fixes tangent problem with SQL_C_WCHAR buffer binding. In case application didn't provide buffer or passes its length is 0, e.g. wanting to get length of available data first, connector would return 0 in StrLen pointer.
I could repeat it with 10.1.17. So it is not 10.2 specific