I've been struggling with using the sql extensions like for xml and
openxml myself, but it seems that Microsoft is really pushing DataSets
now with the addition of ADO.NET, instead of using XML or DataReaders.
Check out
http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/11/datapoints/TOC.asp
and
http://www.knowdotnet.com/articles/datarelation.html to start, then
maybe
http://msdn.microsoft.com/msdnmag/issues/04/05/DataPoints/ as
well. If you just write your query as "select * from table1" you can
use a DataAdapter to read it in, fill a DataSet, then use the DataSet's
GetXml() method if you want to transform it to xml. Or use the
DataSet's ReadXml() method to read in an xml string or xml document
from file. Or the WriteXml() method to write the DataSet in XML form
to a file. You can even read in an xml xsd schema with the DataSet's
ReadXmlSchema() method. It almost seems like Microsoft has taken a
step back by banking on DataSet's, but they've really got some pretty
good arguments for using them. One thing they also give you that XML
doesn't is the ability to establish constraints with the DataTable and
DataRelations, instead of using a schema. It's more integrated, and
provides a better way of inserting/updating/deleting records in a
database. Check out
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql25xmlbp.asp
to see this in practice, by using UpdateGrams to manage data change.
Plus, the DataSets don't duplicate data like a join on several tables
will produce. It's a hierarchical vs. relational model. This may be
more for a disconnected database model, or for use on the Web, for
better speed, but I'm almost seeing at this point to get away from the
old way of doing things with DataReaders, event though they're fast.
They have their place, if you're only needing fast, read-only access to
the data though. It almost seems like DataSets are replacing the old
XML/DOM model, but I'm really just starting to get a handle on the
DataSets. Good luck,
--Steve