Answer Posted / 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.

List the 4 common ado.net namespaces?

1172

---

What is the meaning of executenonquery?

1066

---

Why do we need ado.net?

969

---

What are the benefits of using ado.net?

1006

---

What is ado.net in vb net?

927

---

Explain the DataAdapter.Update() and DataSetAcceptChanges() methods.

1016

---

Describe ado.net object model in detail.

998

---

Define ado.net?

1115

---

What is defaultview in datatable?

1028

---

What is the difference between the clone() and copy() methods of the dataset class?

1089

---

What are the advantages of ado.net?

914

---

What are the steps to connect to a database?

1024

---

What is isolation?

1024

---

Which database is the ado.net?

976

---

What does executereader return?

983

---