DataAdapter V DataReader

hog

Well-known member
Joined
Mar 17, 2003
Messages
984
Location
UK
A bit late for the app Ive 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?
 
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). Weve 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
 
Thats interesting. Ive 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 wont deny that, however to use them as an end-all solution to data access is rather lazy. If youve ever implemented a DAL that returns business objects youre absolutely kidding yourself if you think a DataSet is an easier method of populating those objects. And thats just one piece of evidence against the DataSets use.
 
Mmm very interesting feedback from you both..thnx:)

Ill digest this and make use of it well :) :)
 
Back
Top