DataReader is connected?

  • Thread starter Thread starter Ray Alirezaei
  • Start date Start date
So,if it really looks connected why microsoft pretends that "DataReader is
ADO.NET SOLUTION IN A COMPLETELY DISCONNECTED APPROACH",so saying all this
we could make a conclusion that Datareader is nothing except a light version
of "Dataset" !!!,,How about that??
 
Sorry,I made a mistake in that last posting,,yes ,,that's correct
,,datareader **MUST** be connected !!!! I was confused!!

So As far as I underestood it caches a portion of data ,not necessarly one
row at a time as microsoft say. and when it reaches the end of the cache
,then it fails .
So contary to dataset which waits until all data become available ,it get
the chuncks of data in the buffer and then the next chunk .My general
confusion was about this sentence that
Datareader get the rows one by one ,which is obviously wrong.but atleast I
know it still uses a buffer which is much smaller that the one Dataset uses
and also it is connected (we don't sense the connectedness until it reaches
the last record in its buffer)

Thanks for helping me to clarify this issue.
 
Yes :
- DataSets are a "in memory" db (disconnected scenario)
- DataReader is a read only forward only cursor (connected scenario). For
performance reasons it reads data in a buffer...

The documentation likely needs to be clarified. I believe they wanted to say
that YOU read the datareader row by row rather than the datareader reads
from SQL Server row by row...

Patrice

--
 
Hi Sahil,
Thanks for your reply,
I searched your blog
(http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/12/11/36078.aspx)
and I found the code as follow:
"SqlDataReader dr = cmd.ExecuteReader(CommandBehavior.CloseConnection);"
Kind of cool but I think something is goofy,why?I'll tell you.
I put :
"MessageBox.Show(nwindConn.State.ToString());" right after the above
code,and to my surprise the connection was still "OPEN".That's why you can
still iterate through Datareader..if you put connection.colse() or
Connection.Dispose() right after the code above and before iteration
through datareader using read methof ,You will notice that Datareader will
complaint about it .I used VS 2003 though so I have no idea about 2005.
I'm happy that this thread has become so hot ,I learnt a lot.
Ray
 
What I think about DataReader in 2005 is that it is still connected but when
you force the connection to be closed by calling
"CommandBehavior.CloseConnection" ,then it retrives all the data.
The whole concept which is the disconnect nature of DataReader shouldn't
have been chnaged(I think) ,there is a trick involving here.

What do u think?

Thanks
Ray
 
Next time just trust me...

David

ALI-R said:
What I think about DataReader in 2005 is that it is still connected but when
you force the connection to be closed by calling
"CommandBehavior.CloseConnection" ,then it retrives all the data.
The whole concept which is the disconnect nature of DataReader shouldn't
have been chnaged(I think) ,there is a trick involving here.

What do u think?

Thanks
Ray
Click to expand...
 
It is not in the matter of trust or distrust,,We disscussed a lot of things
,anyways at least now I knw that VS 2005 treats DataReader differently and
it worth posting all those messages and encouraging poeple to answer
,dosen't it?

Take care
 
Ray,

I agree your question reflects the true knowledge thirsty geek in you. That
is a good quality.

BTW, to tell you "What do I think".. 3 things

a) I'd like to test out my concept in VS2003 myself before I believe ya :)
LOL. Because I checked reflector's code in .NET 1.1 and i can't see any
behavior differences, so I'm shocked that there really should be any.
b) I think we are worrying about "how did they grow peanuts on a 747".
c) I think if we follow MS recommendations - we'll be out of trouble in the
long run. If 8 bit dos apps can run on 64 bit longhorn - there's something
to be said about MS's tendency to go to crazy exteremes to ensure it's
customer's software doesn't break. True there will be horror stories but all
I gotta say is .. it's much better than the other side. far far better.

Anyway, thanks for the very invigorating talk on DataReaders. Keep 'em
comin'

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Sahil,
Thanks for monitoring and guiding this thread to the right direction.I was
re-reading the thread from the beginning and I noticed that it has gone
through a very good path to the answer.very informative specifically by
testing ways that you did, I got a very good approach for future
issues.Specially that one in which you shut down the computer ,it was so
smart of you to make sure there is no SQLSERVER (Running or STOPPED) to
server the datareader.I think you got an error in that case which reveals
very important fact :

"Datareader uses a network buffer which makes it look 'disconnected',but it
is not TRUE ,because as soon as Read method of DataReader reaches the end of
buffer,The "Connectedness" nature of Datareader is revealed (That's when you
shut down the computer to get that error:-)) GOOD JOB-I LOVE IT)) "

Good conclusion ! my email address is (e-mail address removed) and I will keep
reading your blog to see if there is a new topics on this issue .

Happy Programming and Blogging!!

Reza (Ray)
 
Thanks Reza,

I am in the midst of authoring yet another book on ADO.NET 2.0. And I have
to deal with such things in absence of books or documentation on Beta
products. :) , it's not a big deal at all writing up a little peice of code
and verify something - check out snippetcompiler. Another good tool is
"Reflector".

These newsgroups have taught me more than anything else. They bring out the
very specific irritating things that are not straightforward in ADO.NET (or
any other such topic), and I think if I were to be able to give my book such
a practical touch, and address the very few core problematic things, it'd be
what a book is supposed to be --- Not MSDN :)

Oh and here is another one --- How do you write a custom constraint?? :-)

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
http://blogs.apress.com/authors.php?author=Sahil Malik
 
Hey Ray,

Check my blog out - someone tested that in VS2003 and he is confirming that
it works in VS2003.
http://dotnetjunkies.com/WebLog/sahilmalik/archive/2004/12/11/36078.aspx?Pending=true

This is in accordance to what I was telling you - I didn't see any thing via
reflector that would lead me to believe that the behavior between VS2003 or
2005 would be any different.

Either way, I am going to run all these tests myself in a couple of days and
post the results on my blog.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
I asked the guy some information.In my box it dosen't work,I'm going to
test it on another computer (at werk) and I'll let you know about it.
 
Sahil,
what I mean by not working is not the fact that there is a bug there ,I mean
The connection is still open after you use
"CommandBehavior.ConnectionClose".IT works fine in VS2003 but it seemes to
be connected.
Cheers bud,
Reza
 
Back
Top