Windows 10

Thank you for your bug report!

Would it be possible to provide ODBC trace for the problem you observe? Or the test case?

I've uploaded the Windows ODBC logfile with the last 2 statements. The second block is my test case with the 'dummy' field.

I hope that's the tracefile you want. If not so please let me know.

Thank you for your efforts.

Hi,
You've pasted here the trace for your workaround with dummy. That's fine, since it still shows sequence of ODBC calls your .Net application does, and presumably it's the same as with the query, that exposes the issue.
However, I could not so far repeat your problem. SQLColAttributeW(SQL_DESC_BASE_TABLE_NAME) returns 'device' for the 1st column after SQLPrepareW(your query)
Could you please try your testcase with latest 2.0 connector(2.0.15 at the moment)? 3.0 is not stable release yet, and it was released relatively long time ago, and thus it does not contain all fixes that 2.0.15 has. I could not repeat your problem with 3.0 as well, but I neither have your complete environment(e.g. table structures), nor I have your complete test-case.
And if it is repeatable with 2.0, and I guess that is the case, could you please provide me your standalone test-case with related table structures?

I've tried it with the ODBC 2.0.13, 2.0.14, 2.0.15 and 3.0.0. I have the same issue in all versions. I use currently the 3.0.0 for development because the performance of the 2.0.15 is extremely bad. The DataReader in version 2.0.14 needs for a certain query 10 seconds and the 2.0.15 for the same query 60 seconds. That's the reason why I'm using the 3.0.0 or 2.0.14.

I've tried to rename the mawa_device.id to mawa_device.id_d and it works fine. Maybe there is a problem with the JOINs of more tables with same columnnames? Maybe the base table name become filled based on column name only?
The position of the id field doesn't matter -> same issue.

I've attached a small testcase with 3 tables and test data. The query I used is:

SELECT d., g. FROM mawa_device_group_assign as a
INNER JOIN mawa_group as g ON g.id = a.group_id
INNER JOIN mawa_device as d ON d.id = a.device_id

For mawa_device.id i get the base table name "mawa_group". I hope you can repeat the issue.

I would appreciate if you reported that 2.0.15 performance regression in separate jira issue!
As for test-case - I was rather talking about short .net program that allows to repeat the issue. Because I tried restore from your ODBC trace short C program, but I could try to repeat what you see. I will try with your exact tables structure, but I doubt it will be different.
Thanks once again for your cooperation

You will find the zip-file with the short C# .NET test-application in the attachment.

I'm using the following version of visual studio for debugging:

Microsoft Visual Studio Professional 2015
Version 14.0.25421.03 Update 3
Microsoft .NET Framework
Version 4.6.01038

My debugger is configured for "Any CPU x64".

Thanks!

Strange. Connector returns correct BaseTableName, but at the end it is wrong. It has smth to do with same name of columns in device and group tables(id) - if rename it in one of fields, your test passes without errors.
That all would look like a bug in ado.net, unless mysql's connector didn't show the same problem. The solution apparently is not straight forward.
May I ask one more time to file a bug about your regression problem? All 2.0.15 stuff has been merged to 3.0 branch, and most probably that regression will show up in next 3.0 release. If we don't eliminate its reason. Thanks in advance.