IDataReader.GetOrdinal return -1 instead of exception

Topics: Data Access Application Block
Apr 25, 2011 at 4:31 PM
Edited Apr 25, 2011 at 4:36 PM

Is there any way that GetOrdinal can return -1 instead of throwing an exception when a field is not found in the IDataReader?

It wouldn't change functionality, as when you go to use the returned value, it will throw an exception.  But it would allow more intelligent handling of when a field is not found without the huge performance penalty of an exception.

Below is what I have:

    <System.Runtime.CompilerServices.Extension()> _
    Public Function ContainsFieldName(dataReader As IDataReader, fieldName As String) As Boolean
        For Index As Integer = 0 To dataReader.FieldCount - 1
            If UCase(fieldName) = UCase(dataReader.GetName(Index)) Then
                Return True
            End If

        Return False
    End Function

Here is what I would have:


    <System.Runtime.CompilerServices.Extension()> _
    Public Function ContainsFieldName(dataReader As IDataReader, fieldName As String) As Boolean
        Return dataReader.GetOrdinal(fieldName) <> -1
    End Function

And the above wouldn't really be needed, since I could just test against -1. Just seems a little stupid on SqlDataReader's part to throw an exception, too.

Otherwise, I would be interested in a new function called Contains(FieldName) and IndexOf(FieldName). This is the consistency with collections I am looking for.
Apr 26, 2011 at 3:38 AM


I believe your question is something not specific to Enterprise Library since its more of a DataReader behavior. I recommend to ask this question on other forums to get a better answer.


Noel Angelo Bolasoc
Global Technologies and Solutions
Avanade, Inc.

Apr 29, 2011 at 9:32 PM

IDataReader is specific to Enterprise Library, but I see that it does mimic the SqlDataReader behavior.  So you're probably right.  I was hoping that Enterprise Library would have more functionality rather than reduced functionality compared to built-in functions.

If I asked another question, what is the advantage to using Enterprise Library Data Blocks rather than directly using .Net's ADO Sql methods like SqlConnection and SqlCommand?  I know both do connection pooling, but is Enterprise Library's connection pooling better?  Or is there any other advantages?

If this question doesn't get answered, no problem.  I would rather not open and track a second question.  But any information would be nice (couldn't find any specifics searching the web).

May 1, 2011 at 2:20 AM

System.Data.IDataReader is in no way specific to Enterprise Library. It's the base interface that all data readers implement, and is one of the foundations of how the .NET framework lets you abstract across different databases.

As far as the advantages of the data access blocks over raw ADO.NET? Simplification. Using the data block, you can call a stored procedure in one line of code, and be assured that the connection is properly opened and closed without having to do it yourself. Entlib itself does connection management, but it doesn't do any separate connection pooling, it just depends on what the ADO.NET provider is doing itself.

In general, I find using the DAAB easier than using raw ADO.NET because the reduction in the amount of boilerplate junk I need to write.