DataAdapter V DataReader

[hog]

A bit late for the app I've just released but can I presume there is an advantage using a DataReader rather than a DataAdapter to populate a ComboBox when the data is not going to changed but is just being used to provide a selectable list?

[Nerseus]

A DataReader is optimized for reading so it will be faster than a DataAdapter, especially for filling tables, combos, etc.

 

Of course, if you have multipe tables to load, a DataAdapter has the advantage of loading all tables at once, which means less calls to the database (one call can retreive 3 or more tables in one shot).

 

I have yet to use a DataReader in production, but only because areas where I need to read data, I need to read a relatively large chunk (and always multiple tables). We've noticed no performance issues doing things this way. We DO utilize webservices to retreive data, and we do so asynchronously so parts of the form can initialize while waiting for the data to stream down from the webmethods.

 

-Nerseus

[Derek Stone]

That's interesting. I've yet to use a DataAdapter or DataSet in a production-level environment. I consider them a very poor solution when code needs only to request data or even when rows need to be inserted or updated. The DataSet is overused, something I attribute to the Microsoft documentation pushing its use far too much. Used under the correct circumstances, a DataAdapter/DataSet pair can alleviate a lot of coding, I won't deny that, however to use them as an end-all solution to data access is rather lazy. If you've ever implemented a DAL that returns business objects you're absolutely kidding yourself if you think a DataSet is an easier method of populating those objects. And that's just one piece of evidence against the DataSet's use.

[hog]

Mmm very interesting feedback from you both..thnx:)

 

I'll digest this and make use of it well :) :)