MySQL Bugs: #47013: NullReferenceException thrown when attempting to change CommandText property

Bug #47013	NullReferenceException thrown when attempting to change CommandText property
Submitted:	31 Aug 2009 11:16	Modified:	10 Sep 2009 6:19
Reporter:	The Assimilator	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / NET	Severity:	S3 (Non-critical)
Version:	6.0.4	OS:	Microsoft Windows (XP Pro SP2)
Assigned to:		CPU Architecture:	Any

Description:
I previously reported this as part of http://bugs.mysql.com/bug.php?id=46930. However I have not found a related bug for this particular case so I am submitting a new one. Please refer to the aforementioned bug for a full description.

In the DataSet designer, changing the CommandText by removing the database name causes the exception shown by the screenshot linked below, and if "Yes" is chosen in that dialog then the DataSet breaks completely (loses all procedure parameters etc.). *This is an intermittent fault that does not occur on all DataSets!*

http://bugs.mysql.com/file.php?id=12776

I have tracked this issue down to the following line in MySql.Data.MySqlClient.MySqlConnection.GetSchema(string collectionName, string[] restrictionValues):

  restrictions = schemaProvider.CleanRestrictions(restrictionValues);

The problem is that the schemaProvider variable is not initialised at the time the method is called, hence causing the NullReferenceException. This is due to the fact that MySql.Data.MySqlClient.MySqlConnection.Open() hasn't been called at this point in time (its ConnectionState is Closed) - I verified this by writing debug info to the system Event Log and an Open() call never appeared there.

I'm not sure why this is happening, but I hope I've given you guys enough info to track down and sort out the problem. :)

How to repeat:
See http://bugs.mysql.com/bug.php?id=46930.

Note that this is not always repeatable.

Suggested fix:
Quick and dirty fix:

Add the following code to the MySql.Data.MySqlClient.MySqlConnection.GetSchema(string collectionName, string[] restrictionValues) method, before schemaProvider.CleanRestrictions() is called:

  if (schemaProvider == null)
  {
    this.Open();
  }

More long-term fix:

Determine why MySql.Data.MySqlClient.MySqlConnection.Open() is not always called before MySql.Data.MySqlClient.MySqlConnection.GetSchema(string collectionName, string[] restrictionValues) and fix that issue - it may be the symptom of a larger underlying problem.

Not S1 as I seem to be the only one experiencing this issue... :p

Hi "Assimilator".

I only have what I had before:
  I think that issue is also addressed in one of the reports. Can't remember which one right now though.

So, I'll for duplicate when time allows.

Sorry Tonci... once again I searched the bug database quite thoroughly and couldn't find anything that seemed similar to this issue, which is why I posted it.

If you could point me to the original bug I'll go away and stop wasting your time! :)

Well, I'm not convinced there is a duplicate... But it hangs in the back of my head so I have to search and see if I remember correctly...
After being run over with thousands of reports, I might very well be wrong.

Assimilator, I tried with 3 different tables, no luck.
Also, I tried removing database name in Query builder and in properties box, all works just fine...
I also tried removing database part while connected and while disconnected from server in server explorer, all worked just fine.

Environment:  
  Remote MySQL server 5.1.31 on OpenSolarisx64
  c/NET 6.0.4 on Win2K8x64 with VS2008Pro
  Tables used had no keys defined, normal primary keys...

Sorry, I should have mentioned - I was using a stored procedure that performs a SELECT as opposed to inline SQL.

Ok now, now does this report relate to your Bug#47021? To me, they appear to be almost the same. Can I close this one then as Bug#47021 is already verified?

Feel free to close it, as long as you add a reference to this bug in #47021. Both bugs describe similar situations when using stored procedures, *but* they differ in that they present different error messages with (presumably) different causes.

Closed, a note will be added to Bug#47021.