Handling Changes

for RuBoard

Today's final brief discussion deals with notifying the DataTable as to when rows should be "committed" to the table. In other words, at some point you need to know that changed, deleted, and inserted rows can simply be treated as regular rows, most likely because they are now synchronized to the data store.

Using AcceptChanges

The DataSet , DataTable , and DataRow classes all expose AcceptChanges methods that perform the same function although, of course, only in the scopes appropriate for the object. As hinted at previously, when AcceptChanges is called on any of the objects, it performs the following tasks in order:

1. It calls the EndEdit method for any rows where changes are pending, causing Proposed values to be copied to Current values.

2. It changes the rows with the row states of Added and Modified to Unchanged , creating an Original version for added rows and copying the Current version to the Original for modified rows.

3. Rows with the Deleted state or that were detached from the table are removed from the table.

4. It clears out any RowError information and sets the HasErrors property to False .

Of course, as mentioned earlier today, calling AcceptChanges can cause exceptions to be thrown if you call it, for example, on the deleted row. In addition, remember that rows in other tables might be affected by calling AcceptChanges on a row in a parent table when the AcceptRejectRule property of a foreign key constraint ( ForeignKeyConstraint ) is set to Cascade .

Using RejectChanges

Obviously, the RejectChanges method is exposed on the same objects as AcceptChanges , but has the reverse effects:

1. It calls the CancelEdit method for any rows where changes are pending, causing Proposed values to be destroyed .

2. It changes the rows with the row states of Deleted and Modified to Unchanged , reverting the Original values to the Current values for Modified rows.

3. Rows with the Added state are removed from the table.

4. It clears out any RowError information and sets the HasErrors property to False .

A typical use of RejectChanges is to undo changes if validation errors are placed in the rows as a result of code run in the events of the DataTable such as RowChanging or ColumnChanging , as shown in Table 4.2. For example, the method in Listing 5.7 attempts to resolve a specific error and, if it cannot, calls RejectChanges on the row. After all the rows have been checked, the method calls AcceptChanges on the entire table.

Listing 5.7 Checking rows. This method checks for a specific error condition and corrects it if possible before calling the RejectChanges or AcceptChanges method.

 private void checkAddressErrors(ref DataTable dt) {   if (dt.HasErrors)   {     foreach (DataRow row in dt.GetErrors())     {       if (row.RowError == "Must have a Postal Code or City and State")       {         row["PostalCode"] = "66218";         row.RowError = "";    // clear the error, sets HasErrors to false       }       else         row.RejectChanges();     }   }   dt.AcceptChanges(); } 

Note in this code snippet that the GetError method of the DataTable is used to retrieve all the rows whose RowError property is set in an array of DataRow objects.

Note

Both the DataSet and DataTable expose Reset methods that simply wipe out all data and columns in the tables, and leave the object in the state it was in directly after it was instantiated . The Reset method would be appropriate to use if you want to clear a DataSet or DataTable and reuse it for a different set of data because neither the data nor structure is preserved.

for RuBoard