Bug #35957 SQLDescribeParam and Longtext
Submitted: 10 Apr 2008 9:54 Modified: 11 Nov 2009 2:38
Reporter: Just Thomas Email Updates:
Status: Won't fix Impact on me:
Category:Connector / ODBC Severity:S2 (Serious)
Version:5.1.3, 3.51.24 OS:Any
Assigned to: CPU Architecture:Any
Tags: datatype, longtext, parameter size, SQLDescribeParam

[10 Apr 2008 9:54] Just Thomas
Wrong datatype and datasize is returned when parameter is longtext. Overwriting other parameters and causing access violations.

How to repeat:
1) Create a table with a longtext. 
2) Update that field via parameter.
3) Check result of SQLDescribeParam
-> It returns datatype 12 (varchar, i.s.o. longvarchar) and datasize of 255.

Suggested fix:
Return longvarchar?
[10 Apr 2008 10:53] Tonci Grgin
Hi Just and thanks for your report. Verified as described with MySQL 5.0.58PB server. Test case attached.
[10 Apr 2008 10:54] Tonci Grgin
Test case

Attachment: Bug35957.cpp (text/x-c++), 3.87 KiB.

[10 Apr 2008 10:57] Tonci Grgin
Same result observed with 3.51 branch.
[14 Apr 2008 8:44] Just Thomas
This is probably not the right place for this but i could not find another. I was just wondering if it will at all be possible to get a built version of the 5.1 driver with this fixed. I do understand this is not how it works (i am in the industry too) - but i am due for release and will need to apply some serious/dirty coding to circumvent this problem.
[14 Apr 2008 9:59] Tonci Grgin
Just, I am sorry but if you don't have support contract entitling you to custom builds/fixes there's not much I (or you) can do... Now it's up to ODBC team leader to asses the importance of this bug and assign people to fix it within some time-line. I've done my best by verifying the bug at once and setting triage to rather serious values.

What you can do is to watch changes in this report and, when patch is committed, pull public source repository (SVN) and build MyODBC yourself with details provided in manual. Or wait for official release.
[25 Apr 2008 8:52] Just Thomas
Further to this, it seems that the parameter type and size is always 12 and 255 respectively. Ouch!
[25 Apr 2008 9:10] Just Thomas
Please can you give me a release schedule for your drivers because making our product MySQL compliant has just grinded to a halt. I cannot possibly code around all of this, nor trust it out in the market.
[26 Apr 2008 8:30] Tonci Grgin
Just no not right now, sorry. But I will check with others on status of this report. In the meantime, please monitor status changes of this report.
[14 May 2008 0:44] Jim Winstead
SQLDescribeParam() will always return the type as SQL_VARCHAR and the length as either 255 or 24MB, depending on whether the 'big packets' option is set.

This is a limitation of how prepared statements are implemented by the driver, and is unlikely to be fixed anytime soon. As the MSDN documentation warns, SQLDescribeParam() is not widely supported.
[29 May 2008 19:39] Just Thomas
I noticed that support for sqlgetdescrec was reported in one of the 2007 (i think it is sept. or dec.) 5.1 alpha releases. Could this be used as an alternative, the reason i ask is because i cannot seem to get the information from it. Now i am wondering if i have the correct version (i have the latest full release) or if it does actually work?

Quoted from http://www.mysql.com/news-and-events/newsletter/2007/2007-09.html :

"New Release of MySQL Connector/ODBC 5.1.0 (Alpha)

MySQL Connector/ODBC 5.1.0-alpha, a new version of the ODBC driver for the MySQL database management system, has been released. This release is the first of the new 5.1 series and is suitable for use with any MySQL server version since MySQL 4.1, including MySQL 5.0, 5.1, and 6.0. (It will not work with 4.0 or earlier releases.) The following is a partial list of changes:

    * Added support for SQL_C_WCHAR.
    * Added support for Unicode functions (SQLConnectW, etc).
    * Added descriptor support (SQLGetDescField, SQLGetDescRec, etc)

View complete list of changes ยป"
[2 Jun 2008 21:42] Jim Winstead
No, SQLGetDescRec() does not provide any different access to this information. It simply is not available from the server at this point.
[3 Jun 2008 8:22] Just Thomas
So would it be a correct assumption that no other "3rd party" drivers will be able to extract this information? Like OpenLink and DataDirect drivers?