MySQL Bugs: #61477: MySqlDataReader GetSchemaTable uses 1-based for ColumnOrdinal

Bug #61477	MySqlDataReader GetSchemaTable uses 1-based for ColumnOrdinal
Submitted:	10 Jun 2011 11:11	Modified:	18 Oct 2013 22:22
Reporter:	Chris Ormesher	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / NET	Severity:	S2 (Serious)
Version:	6.3.6	OS:	Any
Assigned to:	Roberto Ezequiel Garcia Ballesteros	CPU Architecture:	Any

Description:
MySqlDataReader GetSchemaTable returns 1-based columnordinals whereas other methods ( eg IsDBNull() ) require 0-based ordinals.

How to repeat:
Create a connection and command with a very simple SELECT statement eg "SELECT 1 as fred". Call the ExecuteReader() method to return a MySQLDataReader object.
Call the GetSchemaTable() method on the reader and look at the DataTable. Column "Fred" will have columnordinal 1.
Call Read() on the reader.
Calling IsDBNull( 1 ) on the reader results in an "Index out of bounds" exception.

Suggested fix:
Correct the GetSchemaTable() method on the MySQLDataReader class to calculate its columnordinals using 0-based.

That's the expected behaviour, according to the MSDN documentation:
http://msdn.microsoft.com/en-us/library/0kct2kw6%28vs.71%29.aspx

ColumnOrdinal:
The ordinal of the column. This is zero for the bookmark column of the row, if any. Other columns are numbered starting with one. This column cannot contain a null value.

The remark that this is according to the documentation does not appear to be currently correct.  The referenced page of documentation was from the .Net Framework 1.1, which is about 9 years old (10 if it was copied from 1.0).  A much more recent version of the documentation (4.0) for the interface is available at http://msdn.microsoft.com/en-us/library/system.data.idatareader.getschematable.aspx and states that the table and its columns are implementation dependant.  links are given to Microsoft's implementors of the interface, and they do contain what I would describe as questionable documentation for the ColumnOrdinal field, but those are not currently required by other implementors.

What's more, Microsoft's own implementations do not appear to agree with their own documentation.  Every example I have tried that uses GetSchemaTable for either SQL Server or Oracle always returnes the ColumnOrdinal values as being zero-based, even if there is no key on the table.  While this may not technically be a "bug" according to the documentation, I would hope that you could make it a fairly serious feature request to bring the MySqlClient in line with other products, while still following the documenation for the interface.

I forgot to add previously that I have created a bug report about the documentation with Microsoft.  Hopefully they will change the docs to fit their implementations soon.

Since the documentation was the reference for the implementation, changing the ordinal base right now could be a major issue because of backward compatibility.

Thank you for the update.  Please see the following bug and update to the documentation.  It includes an explanation as to why the documentation was incorrect in the first place (copy and paste):

https://connect.microsoft.com/VisualStudio/feedback/details/724323/documentation-issue-for...

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqldatareader.getschematable...

Microsoft acknowledged this as something to be changed in the documentation, and the current documentation specifies that the values returned by GetSchemaTable() for ColumnOrdinal are to be zero-based.  I was waiting until the documentation was actually updated (there was a delay), and forgot to revisit and update this topic.

I understand that your software was written per previous documentation which was unclear or incorrect, but as of the current .Net specs, this value does not agree with the documentation and is an outlier.  Indeed, I had to write one-off code in a platform independent System.Data consumer to accommodate this.  I no longer use MySQL, so I'll leave it in your hands to decide whether it is better to preserve backward compatibility for users of your product or to be in line with the current documentation and other implementers of the same interface.