MySQL Bugs: #14225: bit column length returned from ODBC is too long

Bug #14225	bit column length returned from ODBC is too long
Submitted:	22 Oct 2005 2:03	Modified:	29 May 2013 11:23
Reporter:	zhou zhongjin	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	3.51	OS:	Windows (windows xp with sp2)
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any

Description:
In mysql server 5.0.13 rc for win32 essential, The length of an expression concat(BitColumn) or cast(BitColumn as char) returned from ODBC is 60 and the lehgth of the same expression returned from the mysql command-line tool is 8 (column BitColumn is defined as bit(60) in mysql server).

How to repeat:
Client Operating system: windows xp with sp2
Development environment: microsoft Visual Foxpro Profession 9.0
Database Connect ODBC: MySQL ODBC 3.51.12

= sqlexec(nConn, "Select Concat(BitColumn) As TestField From TestTable")

The column named BitColumn is defined as bit(60) in mysql server that is installed on same machine. The length of the field TestField in the cursor returned from foxpro function sqlexec is 60 other than 8.

Hi Zhou and thanks for your report. We appologize for the delay, somehow this report got neglected...

> In mysql server 5.0.13 rc for win32 essential, The length of an expression concat(BitColumn) or cast(BitColumn as char) returned from ODBC is 60 and the lehgth of the same expression returned from the mysql command-line tool is 8 (column BitColumn is defined as bit(60) in mysql server).

How did you come about this result? Consider the following test:
C:\mysql507\bin>mysql -uroot -T test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.0.38-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create table testbug14225 (
    -> ID INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    -> BitCol BIT(60),
    -> VCCol VARCHAR(50));
Query OK, 0 rows affected (0.06 sec)

mysql> select * from testbug14225;
Field   1:  `ID`
Catalog:    `def`
Database:   `test`
Table:      `testbug14225`
Org_table:  `testbug14225`
Type:       LONG
Collation:  binary (63)
Length:     10
Max_length: 0
Decimals:   0
Flags:      NOT_NULL PRI_KEY UNSIGNED AUTO_INCREMENT NUM PART_KEY

Field   2:  `BitCol`
Catalog:    `def`
Database:   `test`
Table:      `testbug14225`
Org_table:  `testbug14225`
Type:       BIT
Collation:  binary (63)
Length:     60
Max_length: 0
Decimals:   0
Flags:      UNSIGNED

Field   3:  `VCCol`
Catalog:    `def`
Database:   `test`
Table:      `testbug14225`
Org_table:  `testbug14225`
Type:       VAR_STRING
Collation:  latin1_swedish_ci (8)
Length:     50
Max_length: 0
Decimals:   0
Flags:

0 rows in set (0.00 sec)

mysql>

----
As you can see, metadata returned for BitCol shows length of 60:
Field   2:  `BitCol`
Catalog:    `def`
Database:   `test`
Table:      `testbug14225`
Org_table:  `testbug14225`
Type:       BIT
Collation:  binary (63)
Length:     60
Max_length: 0
Decimals:   0
Flags:      UNSIGNED

So, how do you support the claim "lehgth of the same expression returned from the mysql command-line tool is 8"?
Can you repeat unwanted behavior outside FoxPro (ie. standalone test case)? FoxPro costs a lot of money and I don't have it at my disposal.
Can you repeat unwanted behavior with MyODBC 3.51.14?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.