a datareader (at least for sqlserver) is a forward only cursor returning
data from the response stream buffer. thus you can not lnow how many rows
there are until you read to the end. on a big query you can read rows while
the server is still performing the query.
this is also why you can not read return paramater from a sp until you've
read all the result sets.
No way other than iterating through the reader. Sometimes the overhead of
doing this is so much that I have seen people running a count query too,
before/after Read() ing the data, if needed.
You might want to post this question in microsoft.public.dotnet.framework.adonet.
As one poster has already, commented, you can still use a DataReader. Just
populate it with 2 resultsets, the first one being the count of rows returns.
then use the DataReader's NextResultSet() method to switch to the one
containing all the rows.
Peter
this is really a bad pattern. it requires running the query twice, and if a
row is inserted/deleted between queries, the wrong answer can appear. to
make the query stable you have to use exclusive lock, or select into a temp
table.
Good point, Bruce, if that precision is critical to the business logic
scenario.
But then, doing so would make it a "good pattern"?
Cheers,
Peter
--
Co-founder, Eggheadcafe.com developer portal: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.
