MySQL Bugs: #30230: Connector .NET does not retrieve the list of tables in MS Report Model (VS 2005)

Bug #30230	Connector .NET does not retrieve the list of tables in MS Report Model (VS 2005)
Submitted:	3 Aug 2007 15:28	Modified:	21 Jan 2014 23:07
Reporter:	Bogdan Degtyariov	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / NET	Severity:	S2 (Serious)
Version:	5.0.7, 5.1.3	OS:	Windows
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any
Tags:	Report Model, visual studio 2005

Description:
Report Model Project in MS Visual Studio 2005 is unable to retrieve the list of the tables in MySQL database. However, it can log-in, so the test connection is reported as successful. If use Native OLE DB client to connect to MS SQL Server everything works ok.

How to repeat:
1. In VS 2005 Solution explorer create a new Report Model Project

2. Add a new data source. NOTE: there is a bug in VS, so in order to get the
   data source created it is necessary to do it as RightMouseClick/Add/New Item/
   /Data Source. This enables the providers list combobox in the appeared dialog.

3. Put the login/password/ and other information needed to establish the 
   connection. Check it with the "Test connection" button.

4. RightMouseClick/Add New Data Source View. Select the newly created data source
   and click Next. Select something in the name matching dialog and click Next.

5. See an empty list of the tables available for including in reports.

I can't verify that this is a bug or not from this limited description however I would not expect this level of integration to work with the 5.0 product.  This is supported with the 5.1 product.  Please try 5.1.3

Verified with version 5.1.3.
Trying to provide more details in terms of .NET connector sources.

Similar problem (well at least with VS2005 Enterprise BI) in Bug#31854.

Can confirm this bug with version 5.1.4, I am using MS VS 2005 8.0.50727.42

Matthias

Patch

Attachment: patch30230.diff (application/octet-stream, text), 1.51 KiB.

We don't like the attached patch.  We will consider other options.

I wanted to clarify my previous comment.  The attached patch would cause a scan of the entire SQL string for every executed command.  We may not be able to avoid this but for now we don't want to incur that kind of overhead.