Difference between DataReader and DataAdapter / DataSet and DataAdapter?

Difference between DataReader and DataAdapter / DataSet and
DataAdapter?

Question Posted / guest

3 Answers
31389 Views
TCS, I also Faced
E-Mail Answers

Answers were Sorted based on User's Feedback

Difference between DataReader and DataAdapter / DataSet and DataAdapter?..

Answer / prakash tiwari

Data Reader will read only one record at a time.So memory
consumption will be less,it is purely connection oriented
it will use connection exclusively when datareader is
closed.the memory will be released on the server machine
and connection will be used for any other purpose.

Data Adapter acts as a mediator between dataset and
database server.
it will read data from the database server and places with
in dataset
the manipulations on the dataset will be updated with the
database server

Is This Answer Correct ?

52 Yes

6 No

Difference between DataReader and DataAdapter / DataSet and DataAdapter?..

Answer / preeti

Let’s take a look at the differences between ADO Recordset
and ADO.Net DataSet:

1. Table Collection: ADO Recordset provides the ability to
navigate through a single table of information. That table
would have been formed with a join of multiple tables and
returning columns from multiple tables. ADO.NET DataSet is
capable of holding instances of multiple tables. It has got
a Table Collection, which holds multiple tables in it. If
the tables are having a relation, then it can be manipulated
on a Parent-Child relationship. It has the ability to
support multiple tables with keys, constraints and
interconnected relationships. With this ability the DataSet
can be considered as a small, in-memory relational database
cache.

2. Navigation: Navigation in ADO Recordset is based on the
cursor mode. Even though it is specified to be a client-side
Recordset, still the navigation pointer will move from one
location to another on cursor model only. ADO.NET DataSet is
an entirely offline, in-memory, and cache of data. All of
its data is available all the time. At any time, we can
retrieve any row or column, constraints or relation simply
by accessing it either ordinarily or by retrieving it from a
name-based collection.

3. Connectivity Model: The ADO Recordset was originally
designed without the ability to operate in a disconnected
environment. ADO.NET DataSet is specifically designed to be
a disconnected in-memory database. ADO.NET DataSet follows a
pure disconnected connectivity model and this gives it much
more scalability and versatility in the amount of things it
can do and how easily it can do that.

4. Marshalling and Serialization: In COM, through
Marshalling, we can pass data from 1 COM component to
another component at any time. Marshalling involves copying
and processing data so that a complex type can appear to the
receiving component the same as it appeared to the sending
component. Marshalling is an expensive operation. ADO.NET
Dataset and DataTable components support Remoting in the
form of XML serialization. Rather than doing expensive
Marshalling, it uses XML and sent data across boundaries.

5. Firewalls and DCOM and Remoting: Those who have worked
with DCOM know that how difficult it is to marshal a DCOM
component across a router. People generally came up with
workarounds to solve this issue. ADO.NET DataSet uses
Remoting, through which a DataSet / DataTable component can
be serialized into XML, sent across the wire to a new
AppDomain, and then Desterilized back to a fully functional
DataSet. As the DataSet is completely disconnected, and it
has no dependency, we lose absolutely nothing by serializing
and transferring it through Remoting.

Is This Answer Correct ?

21 Yes

13 No

Difference between DataReader and DataAdapter / DataSet and DataAdapter?..

Answer / anul haq

When accessing data the DataReader is the hands down winner.
Performance increases almost exponentially over the DataSet
when more than a few queries are executed sequentially.

Simple, fast forward, read-only access to result sets is the
DataReader's favorite pastime. If data doesn't need to be
modified, cached or serialized consider using a reader.

Don't dismiss the DataReader just because you need results
in XML. Try using the ExecuteXmlReader method of the
SqlCommand class. Just don't forget the FOR XML clause in
your query.

Business applications with a strong BLL that coerce
requested data into new types can use a DataReader without
fear of lost scalability. Often times the application's
business objects can easily duplicate or enhance some of the
functionality that the DataSet is so popular for. Creating
those business objects can mean the difference between an
application that entirely relies on DataSets to one that can
leverage their usefulness only where need be.

Binding of read-only data is much more efficient using a
reader. Just imagine how many times a day that DropDownList
you use is populated. Remember how much things cost in the
long run.