MySQL Bugs: #28820: Varchar Field length is reported as larger than actual

Bug #28820	Varchar Field length is reported as larger than actual
Submitted:	31 May 2007 22:51	Modified:	1 Feb 2008 23:26
Reporter:	Jess Balint	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	5.1 alpha	OS:	Any
Assigned to:	Jim Winstead	CPU Architecture:	Any

Description:
Varchar/text field lengths are reported 3 times greater than actual character length. This is due to the use of Utf8 in the character_set variables.

How to repeat:
Use SQLDescribeCol for a Varchar field

Suggested fix:
Report correct character length of columns.

Verified as described with attached test case:

Connecting to myodbc1
COLUMN_NAME -> VCfld
COLUMN_TYPE -> 12
COLUMN_LENGTH -> 75
SQL_DESC_BASE_COLUMN_NAME -> VCfld
SQL_DESC_LABEL -> VCfld
SQL_DESC_TYPE_NAME -> varchar
SQL_DESC_DISPLAY_SIZE  -> 75
SQL_DESC_LENGTH  -> 75
SQL_DESC_OCTET_LENGTH   -> 75

C:\mysql507\bin>mysql -uroot -T test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.0.38-log Source distribution

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

mysql> create table testbug28820( VCfld VARCHAR(25)) default charset utf8;
Query OK, 0 rows affected (0.09 sec)

Related to Bug#27862.

Modified test case to show the problem

Attachment: Bug27862.cpp (text/x-c++), 6.30 KiB.

I got equal resul fort CHAR field and ODBC driver 5.0.12
In table has field length 10 but ODBC driver return 30.

drop table XXT003I; 
create table XXT003I (XX000 Integer, XX001 CHAR(10) ) ENGINE=INNODB DEFAULT CHARSET=cp1250; 
INSERT INTO XXT003I (XX000,XX001) VALUES (1,'ěščřž');

Full ODBC trace log: [url]http://disk.jabbim.cz/gorila@dione.zcu.cz/ODBC%205.00%20return%20for%20CHAR%20field%20trip...] 

config 2dc-180 EXIT SQLDescribeCol with return code 0 (SQL_SUCCESS) 
HSTMT 020D1BB0 
UWORD 1 
UCHAR * 0x0012F3A4 [ 5] "XX001" 
SWORD 255 
SWORD * 0x0012F11A (5) 
SWORD * 0x01C49544 (1) 
SQLULEN * 0x01C4954C (30) 
SWORD * 0x01C49550 (0) 
SWORD * 0x0012F112 (1)

The fix for Bug #32161 actually cleared this up, because fields in a character set different from that of the connection's "ANSI" character set are identified as SQL_WVARCHAR columns.