Re: Under the hood of DataReader

From: Cowboy \(Gregory A. Beamer\) (NoSpamMgbworld_at_comcast.netNoSpamM)
Date: 02/13/04


Date: Fri, 13 Feb 2004 08:32:38 -0600

First, let's make sure we understand our terms.
1. Server is the database server
2. Client is the software getting data (the one that opened the connection).
This can be a fat client or a web app.

The method of the data reader is simliar to any fast forward (firehose)
cursor on the server side. The information is streamed directly from the
database. On the client, the reader will require some form of buffer to hold
the data. It is a very short term buffer, as it is cleared when the
connection closes (NOTE: Until GC, the memory is not necessarily cleared,
but the data is no longer accessible).

When the DataReader is read, each "row" is destroyed from the stream
(buffer) as it is consumed. When closed, or the connection is closed, all
"rows" are destroyed. There is no built in persistence of the data, ala a
DataSet, so the data effectively dies if you do not store it in your app
somehow.

I know of a programmer who only uses DataReaders. He likes the perf. Problem
is his apps are much more complex and harder to maintain due to his refusal
to use a DataSet. I tend to err on the side of maintainability until I find
a perf problem. I would also caution anyone who decides that the ONLY way to
work with data is a DataReader, for performance reasons, as your app will
likely be maintained by someone who is not as educated (and perhaps not as
smart) as you.

-- 
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
**********************************************************************
Think Outside the Box!
**********************************************************************
"Yasutaka Ito" <nobody@nonexistent.com> wrote in message
news:e66x%23Zj8DHA.2480@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> My friend had a little confusion about the working of DataReader after
> reading an article from MSDN. Following is a message from him...
>
> <!-- Message starts -->
> I was going thru DataReader in ADO.NET in MSDN and there is a confusion
> regarding the buffering
> of data in case of DATAREADER. The link for MSDN JAN 2004 is -
>
>
ms-help://MS.MSDNQTR.2004JAN.1033/cpguide/html/cpconTheADONETDataReader.htm
> At this link, they say that :
> Results are returned as the query executes, and are stored in the network
> buffer on the client until you request them using the Read method of the
> DataReader
> That's in the starting part of the article. Later in the same article, it
is
> said that DataReader provides unbuffered stream....
>
> The DataReader provides an unbuffered stream of data..................
> DataReader is a good choice when retrieving large amounts of data because
> the data is not cached in memory.
> So, there is no buffering in the primary memory going on but there is some
> network buffer. If there is, where is the network buffer - in the NIC or
> some Router or other Gateway... ??
> And whether at all, data in case of DataReader is buffered or not.. ??
> <!-- Message ends -->
>
> The way I understood it is as follows, but wanted to confirm it with you
> foloks before I rant foolishly. Would appreciate further inputs or
> corrections, which I most probably need.
>
> - data is streamed to the client machine and gets queued up until it is
> processed or the data reader is closed
> - application (that's making the request) is given the starting pointer to
> the data coming in
> - data consumed by the application is destroyed as it is used (by calling
> the Read method), similar to electricity...
> - term 'buffer' in the unbuffered means not getting buffered in the
> application's memory space, as with DataSet
>
> thanks!
> -Yasutaka
>
>


Relevant Pages

  • Re: Under the hood of DataReader
    ... DataReader is provider-specific; we only provide guidelines of what would be ... sending rows to the client over the network in packets. ... we'll eventually have a packet on the client buffer ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Under the hood of DataReader
    ... DataReader is provider-specific; we only provide guidelines of what would be ... sending rows to the client over the network in packets. ... we'll eventually have a packet on the client buffer ...
    (microsoft.public.dotnet.general)
  • Re: Socket write behaviour is inconsistent?
    ... copy 1 byte to buffer, copy many bytes to buffer, copy one byte to ... Then why did you write "the client throws an error"? ... remote endpoint for your connection. ... When the response is sent using the first chunk of code, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: TCPClient Synchronous or Asynchronous Writes
    ... acting as the "server" receives quality assurance data from different ... Each client can register to look at differnt data so there ... is actually a Circular Buffer for each client. ... >> stream data to my clients over a TCPClient connection. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Under the hood of DataReader
    ... Client is the software getting data (the one that opened the connection). ... the reader will require some form of buffer to hold ... When the DataReader is read, each "row" is destroyed from the stream ...
    (microsoft.public.dotnet.framework.adonet)