| Bug #27790 | MyODBC 3.51.14 returns wrong length for varchar binary columns | ||
|---|---|---|---|
| Submitted: | 12 Apr 2007 18:32 | Modified: | 3 May 2007 17:45 |
| Reporter: | Tom Price | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S2 (Serious) |
| Version: | 3.51.14 | OS: | Windows (2000 SP4) |
| Assigned to: | CPU Architecture: | Any | |
[12 Apr 2007 19:52]
Tom Price
MySQL version is 4.0.20a-nt on Windows 2000 SP4. Tables are MyISAM.
[14 Apr 2007 10:45]
Tonci Grgin
Hi Tom and thanks for your report. MS Visual FoxPro can not process VARCHAR fields longer than 255 characters, nor can Delphi, for example (same mapping to Memo happens). We are aware of this problem (please see Bug#10491). This represents grave issue for all connectors. They can't work around it, at least not reliably. Ad hoc user queries do not allow connector to distinguish between "SHOW CREATE TABLE", where it should treat BIANRY as UTF8, and "SELECT varbinary_col FROM some_table", where it really should be binary... I'm setting this to "Verified" even though it's actually duplicate of Bug#10491. Bogdan, can we do anything about this?
[2 May 2007 18:12]
Tom Price
A "show table status" query using 3.51.14 returns columns "name", "engine", "row-format", "collation", "create_options", and "comment" which are incorrectly converted to "General" fields by Visual Foxpro. General fields are typically used to store OLE objects. This poses a very serious issue. Unlike memo fields, general fields cannot be programmatically converted to a character data type.
[3 May 2007 5:49]
Tonci Grgin
Tom, as I said, FoxPro column mapping is nothing we can fix. Even though the behavior bothering you was introduced in 3.51.14 for a *good* reason seems we will have to roll back the changes. Please be patient until next release of MyODBC is available...
[3 May 2007 17:45]
Bogdan Degtyariov
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.
If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at
http://dev.mysql.com/doc/en/installing-source.html
Description: varchar binary fields are incorrectly returned with a length of 4097. Since the length > 255, Visual Foxpro maps these fields to a "Memo" instead of a "Char" local data type, affecting many aspects of its processing. This behavior is a change from 3.51.12. Plain (non-binary) varchar fields still appear to be processed correctly. How to repeat: create table foo(a varchar(16) binary); insert into foo values('test'); In Visual Foxpro: SQLEXEC(setup.nConn,"select * from foo ") BROWSE SQL trace: vfp7 f48-818 ENTER SQLExecDirect HSTMT 022E1C68 UCHAR * 0x01D5AFF0 [ -3] "select * from foo \ 0" SDWORD -3 vfp7 f48-818 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UCHAR * 0x01D5AFF0 [ -3] "select * from foo \ 0" SDWORD -3 vfp7 f48-818 ENTER SQLNumResultCols HSTMT 022E1C68 SWORD * 0x0012E734 vfp7 f48-818 EXIT SQLNumResultCols with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 SWORD * 0x0012E734 (1) vfp7 f48-818 ENTER SQLNumResultCols HSTMT 022E1C68 SWORD * 0x0012E4FC vfp7 f48-818 EXIT SQLNumResultCols with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 SWORD * 0x0012E4FC (1) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 2 <SQL_COLUMN_TYPE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 2 <SQL_COLUMN_TYPE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 (-3) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 6 <SQL_COLUMN_DISPLAY_SIZE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 6 <SQL_COLUMN_DISPLAY_SIZE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 (16) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 4 <SQL_COLUMN_PRECISION> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 4 <SQL_COLUMN_PRECISION> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 (16) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 5 <SQL_COLUMN_SCALE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 5 <SQL_COLUMN_SCALE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 (0) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 7 <SQL_COLUMN_NULLABLE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 7 <SQL_COLUMN_NULLABLE> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 (1) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 9 <SQL_COLUMN_MONEY> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 9 <SQL_COLUMN_MONEY> PTR 0x00000000 SWORD 0 SWORD * 0x00000000 SQLLEN * 0x0012E500 (0) vfp7 f48-818 ENTER SQLColAttributes HSTMT 022E1C68 UWORD 1 UWORD 1 <SQL_COLUMN_NAME> PTR 0x0012E284 SWORD 255 SWORD * 0x00000000 SQLLEN * 0x0012E500 vfp7 f48-818 EXIT SQLColAttributes with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 UWORD 1 <SQL_COLUMN_NAME> PTR 0x0012E284 SWORD 255 SWORD * 0x00000000 SQLLEN * 0x0012E500 (0) vfp7 f48-818 ENTER SQLFetch HSTMT 022E1C68 vfp7 f48-818 EXIT SQLFetch with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 vfp7 f48-818 ENTER SQLGetData HSTMT 022E1C68 UWORD 1 SWORD -2 <SQL_C_BINARY> PTR <unknown type> SQLLEN 4097 SQLLEN * 0x0012E318 vfp7 f48-818 EXIT SQLGetData with return code 0 (SQL_SUCCESS) HSTMT 022E1C68 UWORD 1 SWORD -2 <SQL_C_BINARY> PTR <unknown type> SQLLEN 4097 SQLLEN * 0x0012E318 (4) Suggested fix: Revert to behavior under 3.51.12.