Normally, they expect developers to know what columns will be in the DataReaders they're retrieving from the database since you typically provide the SQL or stored procedure name to execute the reader in the first place.
- An interface can't force an implementation
- A query with an outer join will return all the columns you request. it's just that some of them will contain the value DBNull. IDataRecord provides a method IsDBNull, and DataRow a method IsNull to test for this case, e.g.
int value = 0; // or whatever default you want
if (!dr.IsNull("column2")) value = dr["column2"];
Joe, ofcourse you are right. I shouldof thought of a better example. An outer join while it did seem perfect for having a non existant column, it is indeed null on non matching columns, so my bad.
I didn't really want to get into the specifics about why i was having non-existant columns but now it's unavoidable :D
Again without getting into the specifics, it turns out that at the time of this writing, an application i was working on had a stored proc returning result sets based on an if statement and branching out. The difference btw the resultsets returned was an abscence of 2 - 3 columns.
This is why, I felt a need for a property that could tell if the column i'm trying to access is non existant versus throwing an error. I'll agree that it's not a very common need, still useful. If i remember correctly, i resolved by using the SqlDataReader.GetSchemaTable Method and walking down the columns returned to test for the existance of the column...not elegant. Alternatively i couldof rewritten the stored proc, but that's another story.
The code I had inherited ofcourse was working around this abscence by wrapping the non possibly non existant columns in a try/catch block, which as you can note from my experimentation above was turning out expensive.
Many thanks for catching my mistake. All much appreciated.