Bug #27158 | MyODBC 3.51/ ADO cmd option adCmdUnknown won't work for tables - regression | ||
---|---|---|---|
Submitted: | 15 Mar 2007 0:16 | Modified: | 14 Mar 2008 18:41 |
Reporter: | Erica Moss | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / ODBC | Severity: | S2 (Serious) |
Version: | 3.51.14, 3.51.20 | OS: | Windows (XP sp2) |
Assigned to: | Jim Winstead | CPU Architecture: | Any |
Tags: | regression |
[15 Mar 2007 0:16]
Erica Moss
[26 Aug 2007 16:06]
Kent Boortz
ADO supports this feature, to give a single table name or a stored procedure name, by trial and error. It tries send the MySQL driver in order "ado_test" "{ call ado_test }" "select * from ado_test" Problem is, between MySQL server 5.0.37 and 5.0.46 the return code for the second try above has changed, making ADO think it is no idea to try the third one. Earlier SQL state 37000 was returned from the SQLExecDirect() call, with the message You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 (1064) Now SQL state S1000 is returned PROCEDURE test.ado_test does not exist (1305) None of the two error codes above are listed on the Microsoft page describing SQLExecDirect(), but there are references to SQL Server returning 37000. The IBM page lists both http://msdn2.microsoft.com/en-us/library//ms713611.aspx http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.odbc.doc/odb... To make this even more interesting, the same sequence of steps tried for the stored procedure 'proc' in the ADO test case "proc" "{ call proc }" "select * from proc" in 5.0.37 the second line will fail with state 37000 complaining about syntax error, and go on trying to access it as a table, and get S0002 "Table 'test.proc' doesn't exist (1146)". But now 5.0.46 correctly executes the "{ call proc }".
[7 Sep 2007 10:02]
Tonci Grgin
Although subscribed I'm not picking up this thread...
[28 Sep 2007 6:36]
Tonci Grgin
Kent is right, see attached trace. The thing is that adCmdUnspecified CommandTypeEnum value (-1) is the default thus when mentioned explicitly (or no CommandTypeEnum value given) the execution fails. I would like to escalate this bug and raise the severity. Eric? Bug#28098 was marked as duplicate of this one.
[28 Sep 2007 6:37]
Tonci Grgin
ODBC trace
Attachment: SQLlog-Bug28098-27158.zip (application/x-zip-compressed, text), 2.60 KiB.
[28 Feb 2008 22:23]
Jim Winstead
Map ER_SP_DOES_NOT_EXIST to the correct SQLSTATE
Attachment: bug27158.patch (text/plain), 1.58 KiB.
[5 Mar 2008 18:18]
Jim Winstead
The fix for this bug has been committed to the source repository, and will be included in 3.51.24.
[14 Mar 2008 18:41]
MC Brown
A note has been added to the 3.51.24 changelog: Using connection.Execute to create a record set based on a table without declaring the cmd option as adCmdTable will fail when communicating with versions of MySQL 5.0.37 and higher. The issue is related to the way that SQLSTATE is returned when ADO tries to confirm the existence of the target object