Which one of these is most efficient when pulling data from Sql Server 
2000 database, sometimes editing on the front end, and then saving the 
changes back to the database.

	DataReaders are hands down the fastest to read, but don't do
anything else.  Any type of updates and you need to roll your own SQL.
DataReaders are akin to the firehose cursor in ADO.

	XmlReader - you'd have to use XmlTextReader or XmlValidatingReader
here to do what you want, and these are slower.  XmlReaders are *great* when
you're making reports and using XSLT to transform them and need to build
relations within a DataSet and make an individual page for each sub-root
level element (case in point: a *.chm help file).  Nothing beats their usage
in this case.

	DataSet - when used with a DataAdapter, if you're using a fairly
simple select statement the DataAdapter can build your INSERT and UPDATE
statements for you which is nice, and tracks changes to the data allowing
you to control when the underlying database is updated.  Of course the
DataSet is designed to be persistant and HTTP isn't (thus ViewState and
Session), but if you're not going to persist your DataSets in ViewState (not
recommended) or Session (good if your web server has alot of memory and
doesn't need high data latency) then use a DataReader and roll your own SQL.

- Chuck

-----Original Message-----
From: Shah Arpan [mailto:AShah2@n...]
Sent: Wednesday, July 10, 2002 1:45 PM
To: ASP+
Subject: [aspx] datasets vs xmlreader vs datareader


Which one of these is most efficient when pulling data from Sql Server 2000
database, sometimes editing on the front end, and then saving the changes
back to the database. 

Thanx Chuck

That helps.



-----Original Message-----
From: Feduke Cntr Charles R [mailto:FedukeCR@m...]
Sent: Wednesday, July 10, 2002 3:04 PM
To: ASP+
Subject: [aspx] RE: datasets vs xmlreader vs datareader


	DataReaders are hands down the fastest to read, but don't do
anything else.  Any type of updates and you need to roll your own SQL.
DataReaders are akin to the firehose cursor in ADO.

	XmlReader - you'd have to use XmlTextReader or XmlValidatingReader
here to do what you want, and these are slower.  XmlReaders are *great* 
when
you're making reports and using XSLT to transform them and need to build
relations within a DataSet and make an individual page for each sub-root
level element (case in point: a *.chm help file).  Nothing beats their 
usage
in this case.

	DataSet - when used with a DataAdapter, if you're using a fairly
simple select statement the DataAdapter can build your INSERT and UPDATE
statements for you which is nice, and tracks changes to the data 
allowing
you to control when the underlying database is updated.  Of course the
DataSet is designed to be persistant and HTTP isn't (thus ViewState and
Session), but if you're not going to persist your DataSets in ViewState 
(not
recommended) or Session (good if your web server has alot of memory and
doesn't need high data latency) then use a DataReader and roll your own 
SQL.

- Chuck

-----Original Message-----
From: Shah Arpan [mailto:AShah2@n...]
Sent: Wednesday, July 10, 2002 1:45 PM
To: ASP+
Subject: [aspx] datasets vs xmlreader vs datareader


Which one of these is most efficient when pulling data from Sql Server 
2000
database, sometimes editing on the front end, and then saving the 
changes
back to the database.