Clean way to check for DataReader at BOF

  • Thread starter Thread starter Joe
  • Start date Start date
J

Joe

Please don't bother responding about "Read(), MoveNext(), or
HasRows()"
It's obvious that .Net does not have a BOF check, which despite the
presumptuous claims by some that it's not needed, it really should be
exposed.

Therefore, I was hoping someone could come up with a clean/consistent
way to check for something that would throw an exception if the
DataReader (SqlDataReader in my case) was still at BOF.
I could then attempt to move the recordset forward within the 'catch'
block.

----------------------------------------------------------------------------


If any are doubting my need for this kind of functionality, since I
have read so many responses that irreverently state that no one should
ever need to know if a DataReader is at the BOF, here is my situation:

I have a business object has a constructor that takes a SqlDataReader
input parameter.

Sometimes, the SqlDataReader is passed from within a loop like:

ArrayList al = new ArrayList();
while (dr.Read())
{
al.Add(new BusinessObject(dr));
}

In this case, the SqlDataReader is already pointing to the record that
I need


In other cases, however, it would be convenient to pass in the results
of an ExecuteDataReader without having to move the recordset pointer
forward first, like:

BusinessObj obj = new BusinessObject(sql.ExecuteDataReader());
 
Hi Joe,

If you was using a dataset it is easy to check for BOF and EOF in the way as
with a recordset)

But comparing a datareader with a recordset is a little bit strange.
A datareader you can compare with a streamreader and therefore has not EOF.
(Only HasRows which tells you that you not reached the end)

I hope this helps?

Cor
 
Joe:

Within the context of not wanting to use Read, MovNext etc, can't you infer
that you are at BOF by virtue of the fact that you Haven't called any of
these methods?

In your example, if you called it within the exectuereader, you'd always be
at the BOF per se. To illustrate, fire executereader and then try to
reference dr(0) or whatever without calliing Read, MoveNext etc, you'll
throw an exception so I think your goal is met.. It seems if this can't be
inferred and you don't want to use any of the DR's methods to determine
where you are at, then a datatable may be a better object for you
 
Your mention of checking for dr(0) and catching an exception is the
cleanest way that I could come up with to determine if I'm at the BOF
as well.

The reason why I can't assume that it's at the BOF, is because
sometimes the constructor might get called within a SqlDataReader loop
with multiple records, and sometimes it's just for one record (the
latter being the case where the DataReader is passed in while still at
the BOF).

Thank you for the feedback. It's much appreciated.
 
One way I get around the problem is to do a modified Do...Loop when I need
to check if the datareader has no records. In other words:

If dr.Read then
'Found some records, so process them
Do
...Process my records here...
Loop While dr.Read 'This gets the next record or ends if no more
records exist
Else
'No records were found, so do your 'no records found' processing here
End If
dr.Close

Of course, I put all this in a Try...Catch block just in case any errors
occur.

May not be the 'best' way, but it works.

Tom
 
Back
Top