Fog Creek Software
Discussion Board




When would you use HasRows()?


Our favorite Angry Coder made this comment in the July/August aspnetPRO Magazine:

"The IDataReader interface in ADO.NET now supports the HasRows property, making it easier to use the lightweight DataReader classes"

?

When I use a datareader, I always do this:

while(dr.Read())
{
    //do stuff
}

if I'm only pulling one row of data, then:

if(dr.Read())
{
    //do stuff
}

When would you use HasRows?

Philo

Philo
Thursday, May 29, 2003

The Read method returns true if there are more rows in a forward only recordset AND advances the row pointer by one each time it is called, whereas HasRows() would tell you if there are any rows in the recordset without advancing the row pointer.  The difference is that HasRows() will tell you if there are any rows without advancing to the next record in the set.  Read also starts at BOF not the first record.

Another $0.00002 from me.

Dave B.
Thursday, May 29, 2003

I guess I didn't answer your question directly, but you would use HasRows() if for some some reason you didn't want to advance to the next record.  Why would you want to do this?

Well if:

if dr.Read()
{
      // recordset is on first row
}
else
{
    // recordset is on first row (is this what we want?)
}

fails your recordset will now be on row 1 instead of BOF. This may or may not be what you want, so you could HasRows() instead.

if dr.HasRows()
{
  // ok our recordset has at least one row
  while (dr.Read())
  {

  }
}
else
{
  // no rows in recordset
}

Dave B.
Thursday, May 29, 2003

Okay, understood, but when would you want to know if a returnset has data, but not read that data?

I'm guessing you might do this in a middle tier layer, where you either return the reader itself or set a return value flag? Or maybe some kind of error checker?

Seems to add complexity without really adding anything to me?

Philo

Philo
Thursday, May 29, 2003

"...Okay, understood, but when would you want to know if a returnset has data, but not read that data? ..."

How about when you want to display one of those groovy "This query has returned no results" screens....... Makes that process a whole lot simpler

Ed
Thursday, May 29, 2003

It might add structure to your code.
 
>> "but when would you want to know if a returnset has data, but not read that data?"

You wouldn't.  I don't think that's the purpose of HasRows().  It is there to facilitate a means by which you can test the recordset WITHOUT advancing the row pointer thus producing more structured, predictable (trying to think of another term here) easy to read? code.

Of course this is just my opinion.

Dave B.
Thursday, May 29, 2003

>> "How about when you want to display one of those groovy "This query has returned no results" screens....... Makes that process a whole lot simpler"

Not really.  You can do that just as easily with:

if dr.Read()
{
  // process first record <- eliminated with HasRows()
  // loop through rest of recordset
}
else
{
  // display error message
}

but with HasRows() it becomes:

if dr.HasRows()
{
  while dr.Read()
  {

  }
}
else
{
  // display error message
}

It eliminates the "process the first record that the read() method read THEN loop through the REST of the results".

I think it's cleaner.

Dave B.
Thursday, May 29, 2003

Ah - Dave B., I think you have it!
I was thinking in terms of "spool through the records" *or* "test if data returned or act on a single record" - didn't think about the cross between the two...

Thanks all!

Philo

Philo
Thursday, May 29, 2003

Even without HasRows() you can still do this:

if (ds.Read())
{
  do
  {
      // process data
  } while (ds.Read())
}
else
{
  // display error
}

which is no less clean than the HasRows version really. I think it's a question of personal preference.

And the horse you rode in on
Thursday, May 29, 2003

I think it's more a matter of when and how you need to process the records and how you are thinking it should be done.  Everyone thinks about it differently.

Example 1:

if (dr.Read())
{
  // proccess the first record because we are using a "test at the top" looping construct and the first record may have to be processed differently than the rest and besides that it is already read because we have called dr.Read()
  while (dr.Read())
  {
    // process the rest of the records
  }
}
else
{
  // handle the "no records case"
}

Example 2:

if (dr.Read())
{
  // process all records the same or use "if" statements in the "test at the bottom" loop to process records differently
  do {

  } while (dr.Read())
}
else
{
  // handle the "no records case"
}

Example 3:

if (dr.HasRows())
{
  // you probably have to use a "test at the top" looping construct here (different people will use different looping constructs depending on how they are thinking about the problem) because you know that there are records returned and you have to read at least one before processing it
}
else
{
  // handle the "no records case"
}

And so ends my doctoral thesis on computer science.  The final conclusion being that loops are loops whether they are test at top or bottom.  Congrats I'm now a Ph.D. in computer science.  (If that's possible, I don't know, I don't own a degree!)

Just Some Dude
Friday, May 30, 2003

HasRows() doesn't cause any data transfer, but it does let you manage getting the data in reasonable chunks.  From a back end getting one row at a time hardly ever really means that.

Simon Lucy
Monday, June 02, 2003

>> "HasRows() doesn't cause any data transfer, but it does let you manage getting the data in reasonable chunks.  From a back end getting one row at a time hardly ever really means that."

What the hell are you rambling about here?  How does HasRows() let you get data in reasonable chunks?  I think you're smoking crack.  Don't you ever have anything of substance to add to a conversation besides big talk that really means nothing?  WTF.


Tuesday, June 03, 2003

What about in the situation where you would like to databind a reader to a grid. If the reader has no rows you would like to know, and display another web page. If the reader has rows you'd like to bind to the grid.

Well, if you have to read the first row to determine whether there are any rows, then when you bind, the first row will not be displayed.

Voila, here is a situation where HasRows is invaluable.

There is peace in the valley!

Randy Bourgeois
Friday, August 27, 2004

*  Recent Topics

*  Fog Creek Home