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.

What is ole data type?

851

---

What is the purpose of using adodb?

900

---

What is the significance of CommandBehavior.CloseConnection ?

1093

---

Compare Data Reader & Dataset in ado.net?

941

---

What is the role of the dataset object in ado.net?

1056

---

Define data adapter?

893

---

Does executenonquery return a value?

883

---

What is ado in agriculture?

888

---

Describe the command object and its method.

963

---

Explain how to find the given query is optimised one or not?

947

---

differance between ADO vs ADO.Net?

993

---

What are the essential features of ado.net?

895

---

What is aggregating data ?

909

---

What is data relation in ado.net?

992

---

What is dataset and datatable in ado.net?

924

---