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.