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:
Category:Connector / NET Severity:S3 (Non-critical)
Version:6.0.4 OS:Windows (XP Pro SP2)
Assigned to: CPU Architecture:Any

[31 Aug 2009 11:16] The Assimilator
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!*


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)

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.
[31 Aug 2009 11:18] The Assimilator
Not S1 as I seem to be the only one experiencing this issue... :p
[31 Aug 2009 11:24] Tonci Grgin
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.
[31 Aug 2009 13:58] The Assimilator
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! :)
[31 Aug 2009 14:20] Tonci Grgin
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.
[9 Sep 2009 6:52] Tonci Grgin
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.

  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...
[9 Sep 2009 12:41] The Assimilator
Sorry, I should have mentioned - I was using a stored procedure that performs a SELECT as opposed to inline SQL.
[9 Sep 2009 13:08] Tonci Grgin
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?
[9 Sep 2009 13:31] The Assimilator
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.
[10 Sep 2009 6:19] Tonci Grgin
Closed, a note will be added to Bug#47021.