C# 4 and .NET 4

Managing Data and relationships: The Dataset Class ❘ 839
When an alteration is made to a column within a DataRow, the ColumnChanging event is raised
on the row’s DataTable. This permits you to override the ProposedValue property of the
DataColumnChangeEventArgs class and change it as required. This is one way of performing some data
validation on column values. If you call BeginEdit() before making changes, the ColumnChanging event
will not be raised. This permits you to make multiple changes and then call EndEdit() to persist these
changes. If you want to revert to the original values, call CancelEdit().
A DataRow can be linked in some way to other rows of data. This permits the creation of navigable links
between rows, which is common in master/detail scenarios. The DataRow contains a GetChildRows()
method that will return an array of associated rows from another table in the same DataSet as the current
row. These are discussed in the “Data Relationships” section later in this chapter.
schema Generation
You can create the schema for a DataTable in three ways:
➤
➤
➤
Let the runtime do it for you.
Write code to create the table(s).
Use the XML schema generator.
The following sections describe these three alternatives.
Runtime Schema Generation
The DataRow example shown earlier presented the following code for selecting data from a database and
populating a DataSet class:
SqlDataAdapter da = new SqlDataAdapter(select, conn);
DataSet ds = new DataSet();
da.Fill(ds, "Customers");
This is obviously easy to use, but it has a few drawbacks as well. For example, you have to make do with
the default column names, which might work for you, but in certain instances, you might want to rename a
physical database column (say PKID) to something more user-friendly.
You could naturally alias columns within your SQL clause, as in SELECT PID AS PersonID FROM
PersonTable; it’s best to not rename columns within SQL, though, because a column only really needs to
have a “pretty” name onscreen.
Another potential problem with automated DataTable/DataColumn generation is that you have no control
over the column types that the runtime chooses for your data. It does a fairly good job of deciding the
correct data type for you, but as usual there are instances where you need more control. For example, you
might have defined an enumerated type for a given column to simplify user code written against your class.
If you accept the default column types that the runtime generates, the column will likely be an integer with a
32-bit range, as opposed to an enum with your predefined options.
Last, and probably most problematic, is that when using
automated table generation, you have no type-safe access
to the data within the DataTable — you are at the mercy
of indexers, which return instances of object rather than
derived data types. If you like sprinkling your code with
typecast expressions, skip the following sections.
Hand-Coded Schema
Generating the code to create a DataTable, replete with
associated DataColumns, is fairly easy. The examples
within this section access the Products table from the
Northwind database, shown in Figure 30-6.
figure 30-6
www.it-ebooks.info