Bug #34272 SQLColumns from ODBCTE32 returns wrong value for database and several other flds

Description:
Using table from Bug#28841 I issued Catalog / SQLColumns in OTBCTE32 getting result similar to this:
Get Data All:
"TABLE_CAT", "TABLE_SCHEM", "TABLE_NAME", "COLUMN_NAME", "DATA_TYPE", "TYPE_NAME", "COLUMN_SIZE", "BUFFER_LENGTH", "DECIMAL_DIGITS", "NUM_PREC_RADIX", "NULLABLE", "REMARKS", "COLUMN_DEF", "SQL_DATA_TYPE", "SQL_DATETIME_SUB", "CHAR_OCTET_LENGTH", "ORDINAL_POSITION", "IS_NULLABLE"
"testÿÿÿÿÿÿÿÿH", <Null>, "bug28841", "Id", 4, TRUNC: "integer unsi", 10, 4, 0, 10, 1, "", <Null>, 4, <Null>, <Null>, 1, TRUNC: "YE"
"testÿÿÿÿÿÿÿÿH", <Null>, "bug28841", "VBFld1", -3, "varbinary", 50, 50, <Null>, <Null>, 1, "", <Null>, -3, <Null>, 50, 2, TRUNC: "YE"
"testÿÿÿÿÿÿÿÿH", <Null>, "bug28841", "VBFld2", -2, "binary", 50, 50, <Null>, <Null>, 1, "", <Null>, -2, <Null>, 50, 3, TRUNC: "YE"
3 rows fetched from 18 columns.

Obviously, TRUNC: "YE" should be just "YES" and "testÿÿÿÿÿÿÿÿH" should be "test". I have attached DM trace where "test" is retrieved as "testr".

At the same time, 5.1.3 shows no problems:
Get Data All:
"TABLE_CAT", "TABLE_SCHEM", "TABLE_NAME", "COLUMN_NAME", "DATA_TYPE", "TYPE_NAME", "COLUMN_SIZE", "BUFFER_LENGTH", "DECIMAL_DIGITS", "NUM_PREC_RADIX", "NULLABLE", "REMARKS", "COLUMN_DEF", "SQL_DATA_TYPE", "SQL_DATETIME_SUB", "CHAR_OCTET_LENGTH", "ORDINAL_POSITION", "IS_NULLABLE"
"test", <Null>, "bug28841", "Id", 4, "integer unsigned", 10, 4, 0, 10, 1, "", <Null>, 4, <Null>, <Null>, 1, "YES"
"test", <Null>, "bug28841", "VBFld1", -3, "varbinary", 50, 50, <Null>, <Null>, 1, "", <Null>, -3, <Null>, 50, 2, "YES"
"test", <Null>, "bug28841", "VBFld2", -2, "binary", 50, 0, <Null>, <Null>, 1, "", <Null>, -2, <Null>, 0, 3, "YES"
3 rows fetched from 18 columns.

How to repeat:
See above.

Suggested fix:
-

DM trace

Attachment: DMtrace.zip (application/x-zip-compressed, text), 3.42 KiB.

Patch for the bug(rev#867)

Attachment: bug34272.patch (text/x-patch), 2.74 KiB.

I'm pretty sure it is actually the 5.1+ version of the MYSQL_FIELD_STRING() macro that is wrong, not the values being changed here.

Lawrin,

Here is the definition of MYODBC_FIELD_STRING:

/* we use 3 here as SYSTEM_CHARSET_MBMAXLEN is not defined in v5.0 mysql_com.h */
# define MYODBC_FIELD_STRING(name, len, flags) \
  {(name), (name), NullS, NullS, NullS, NullS, NullS, (len) * 3, 0, 0, 0, 0, \
    0, 0, 0, 0, (flags), 0, UTF8_CHARSET_NUMBER, MYSQL_TYPE_VAR_STRING}

As you can see the length is already multiplied by 3: ((len) * 3)
Why should it be done outside as MYODBC_FIELD_STRING("TYPE_NAME", 20*SYSTEM_CHARSET_MBMAXLEN, NOT_NULL_FLAG),?

With the above implementation of MYODBC_FIELD_STRING the problem is not longer happening. I think the bug just should be closed.

Bogdan, look again. There are three implementations of MYODBC_FIELD_STRING() -- for servers >= 5.1, for servers >= 4.1 and < 5.1, and one for earlier servers. The implementation for servers >= 5.1 is missing the * 3 (or * SYSTEM_CHARSET_MBMAXLEN), which may be a source of problems.

Yes, we discussed that with Bogdan today.

Actually in my first try to fix this or other similar bug, I changed MYODBC_FIELD_STRING macro. But in resulted in many test fails. The reason is that NAME_LEN macro used for len parameter of MYODBC_FIELD_STRING in many places does multiplication by SYSTEM_CHARSET_MBMAXLEN. So instead of changing NAME_LEN as well, I added multiplication of problematic parameter values.
BUt probably you are right - to change both macros is better idea.

This bug is fixed by the patch for the Bug#37621. However I'll probably push the tescase for this bug - more testcases is better.

Since the bugs are not really duplicates(1st edition Bug#37621 patch made them duplicates though), I'm just closing this bug.