Database Reference
In-Depth Information
After creation of data set and data adapter, Store data set into the xml file.
// Create and Fill Dataset
DataSet ds = new DataSet();
da.Fill(ds, "Production.Product");
// Extract dataset to XML file
ds.WriteXml(@"c:\productstable.xml");
Note that the XML has simply mapped the data set as a hierarchy. The first XML element,
<NewDataSet>
, is the data set name (defaulting to
NewDataSet
since you don't specify one). The next
element,
<Production.Product>
, uses the data table name (you have only one data table since you use
only one query to populate the data set), and it's nested inside the data set element. The data column
elements,
<Name>
and
<ProductNumber>
, are nested inside this element.
The data for each column appears (as plain text) between the
start tag
(for example,
<Name>
) and the
end tag
(for example,
</Name>
) for each column element. Note that the
<Production.Product>
elements
represent individual rows, not the whole table. So, the column elements are contained within the start
tag
<Production.Product>
and end tag
</Production.Product>
for each row.
If you scroll to the bottom of the XML file, you'll find the end tag
</NewDataSet>
for the data set.
Understanding Typed and Untyped Data Sets
Data sets can be
typed
or
untyped.
The data sets you've used so far have all been untyped. They were
instances of
System.Data.DataSet
. An untyped data set has no built-in schema. The schema is only
implicit. It grows as you add tables and columns to the data set, but these objects are exposed as
collections rather than as XML schema elements. However, as we mentioned in passing in the previous
section, you can explicitly export a schema for an untyped data set with
WriteXmlSchema
(or
WriteXml
).
A typed data set is one that's derived from
System.Data.DataSet
and uses an XML schema (typically
in an
.xsd
file) in declaring the data set class. Information from the schema (tables, columns, and so on)
is extracted, generated as C# code, and compiled, so the new data set class is an actual .NET type with
appropriate objects and properties.
Either typed or untyped data sets are equally valid, but typed data sets are more efficient and can
make code somewhat simpler. For example, using an untyped data set, you'd need to write this:
ds.Tables[o].Rows[o]["CompanyName"];
to get the value for the CompanyName column of the Customers table, assuming that the data table was
the first in the data set. With a typed data set, you can access its data tables and data columns as class
members. You could replace the previous code with this:
ds.Customers[o].CompanyName;
making the code more intuitive. In addition, the Visual Studio code editor has IntelliSense support for
typed data sets.
Typed data sets are more efficient than untyped data sets because typed data sets have a defined
schema, and when they're populated with data, runtime type identification and conversion aren't
necessary, since this has been taken care of at compile time. Untyped data sets have a lot more work to
do every time a result set is loaded.
However, typed data sets aren't always the best choice. If you're dealing with data that isn't well
defined, whose definition dynamically changes, or is only of temporary interest, the flexibility of untyped
data sets can outweigh the benefits of typed ones.
This chapter is already long enough. Since we're not concerned with efficiency in our small sample
programs, we won't use typed data sets, and we don't need to cover creating them here.
