MySQL Bugs: #86762: Error returned by MySQL Server via ODBC/Connector and MS ADO

Bug #86762	Error returned by MySQL Server via ODBC/Connector and MS ADO
Submitted:	20 Jun 2017 18:39	Modified:	28 Aug 2017 10:07
Reporter:	Paul Crowley	Email Updates:
Status:	Analyzing	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	5.3.8	OS:	Windows (Windows 10)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
In the course of discovering some problems with an ODBC application that works on MS SQL Server and used to work on MySQL 5.0, some problems have been encountered.  This is the first of several bug reports on what has been found.
They are being reported separately for tracking purposes.

What happens here is through a legal set of operations via MS ADO something bad happens (not clear if this is in ADO or MySQL Connector/ODBC) but the result is that the contents of a column value replace the column name in the statement.

Version 5.2 of Connector/ODBC (correctly) reports the error message that comes from MySQL Server, but 5.3.8 does not.  This error was reported as #86761.

This operation works fine with Connector/ODBC 5.1 so something happened after that to create the situation where the column name/value are corrupted.

How to repeat:
Attached is an application which will produce the error as well as the source for building the application.  Originally, Visual Studio C++ 2013 was used for building this, but almost any version of Visual Studio should work for this.

Hi Paul,

Thank you for reporting a bug in MySQL ODBC driver and for providing us with the test case.
Unfortunately, it depends on a number of external tables (site_info, user_info, image_info etc), so were not able to check the actual problem. Would it be possible to narrow it down to the actual failure without the use of multiple tables? Or, at least give us the SQL dump for the tables your test case is working with. Preferable if the dump only contains the test data (not the real one) or no data at all if the test can run without it.
Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I have attached the create script for the tables and the application works fine with empty tables.  No data is required to run to the point of failure.  In fact, I believe only the site_info and user_info tables are required for the application to reach the point of failure.  However, adding them all will allow the application to complete successfully when the problems are fixed.