Bug #69554 | SQL_ATTR_MAX_ROWS breaks catalog functions | ||
---|---|---|---|
Submitted: | 23 Jun 2013 18:39 | Modified: | 14 Aug 2013 10:05 |
Reporter: | Sam Varshavchik | Email Updates: | |
Status: | Patch pending | Impact on me: | |
Category: | Connector / ODBC | Severity: | S2 (Serious) |
Version: | 5.1.11, 5.2.5 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[23 Jun 2013 18:39]
Sam Varshavchik
[24 Jun 2013 10:19]
Bogdan Degtyariov
Hi Sam, Thank you very much for reporting the problem in MySQL Connector/ODBC. I was able to repeat the bug in ODBC driver versions 5.1.11 and 5.2.5. Setting the bug status to Verified.
[24 Jun 2013 10:23]
Bogdan Degtyariov
C test case in my_catalog2.c (t_bug69554)
Attachment: my_catalog2.c (text/plain), 46.86 KiB.
[6 Aug 2013 13:03]
Hemant Dangi
Hello Sam, It is not a bug. SQL_ATTR_MAX_ROWS applies to catalog function as well. Please check SQL_ATTR_MAX_ROWS from below msdn link: http://msdn.microsoft.com/en-us/library/windows/desktop/ms712631(v=vs.85).aspx "SQL_ATTR_MAX_ROWS applies to all result sets on the Statement, including those returned by catalog functions."
[6 Aug 2013 13:24]
Sam Varshavchik
That applies to the /same/ statement handle only. The bug is when you use a completely different statement handle, from the same connection, to execute a catalog function. All statement handles share the same SQL connection. The connector implements SQL_ATTR_MAX_ROWS by setting @@sql_select_limit connection setting, before executing a query. The SQL_ATTR_MAX_ROWS value is kept in the statement handle, but the catalog functions fail to set @@sql_select_limit before executing the catalog query, which ends up using whatever @@sql_select_limit was set for the last query executed on the same connection.