Fixed missing enumeration fields.

Author: gewarren

docs/data-tools/relationships-in-datasets.md

@@ -69,10 +69,10 @@ The rules that you can make are specified in the <xref:System.Data.Rule> enumera
 
 |Foreign-key constraint rule|Action|  
 |----------------------------------|------------|  
-|<xref:System.Data.Rule>|The change (update or delete) made to the parent record is also made in related records in the child table.|  
-|<xref:System.Data.Rule>|Child records are not deleted, but the foreign key in the child records is set to <xref:System.DBNull>. With this setting, child records can be left as "orphans"—that is, they have no relationship to parent records. **Note:**  Using this rule can result in invalid data in the child table.|  
-|<xref:System.Data.Rule>|The foreign key in the related child records is set to its default value (as established by the column's <xref:System.Data.DataColumn.DefaultValue%2A> property).|  
-|<xref:System.Data.Rule>|No change is made to related child records. With this setting, child records can contain references to invalid parent records.|  
+|<xref:System.Data.Rule.Cascade>|The change (update or delete) made to the parent record is also made in related records in the child table.|  
+|<xref:System.Data.Rule.SetNull>|Child records are not deleted, but the foreign key in the child records is set to <xref:System.DBNull>. With this setting, child records can be left as "orphans"—that is, they have no relationship to parent records. **Note:**  Using this rule can result in invalid data in the child table.|  
+|<xref:System.Data.Rule.SetDefault>|The foreign key in the related child records is set to its default value (as established by the column's <xref:System.Data.DataColumn.DefaultValue%2A> property).|  
+|<xref:System.Data.Rule.None>|No change is made to related child records. With this setting, child records can contain references to invalid parent records.|  
 
  For more information about updates in dataset tables, see [Save data back to the database](../data-tools/save-data-back-to-the-database.md).  
 

docs/data-tools/save-data-back-to-the-database.md

@@ -133,11 +133,11 @@ Two-stage update process and the role of the DataRowVersion in a successful upda
 
 |DataRowState Value|Description|  
 |------------------------|-----------------|  
-|<xref:System.Data.DataRowState>|The row has been added as an item to a <xref:System.Data.DataRowCollection>. (A row in this state does not have a corresponding original version since it did not exist when the last <xref:System.Data.DataRow.AcceptChanges%2A> method was called).|  
-|<xref:System.Data.DataRowState>|The row was deleted using the <xref:System.Data.DataRow.Delete%2A> of a <xref:System.Data.DataRow> object.|  
-|<xref:System.Data.DataRowState>|The row has been created but is not part of any <xref:System.Data.DataRowCollection>. A <xref:System.Data.DataRow> object is in this state immediately after it has been created, before it has been added to a collection, and after it has been removed from a collection.|  
-|<xref:System.Data.DataRowState>|A column value in the row has changed in some way.|  
-|<xref:System.Data.DataRowState>|The row has not changed since <xref:System.Data.DataRow.AcceptChanges%2A> was last called.|  
+|<xref:System.Data.DataRowState.Added>|The row has been added as an item to a <xref:System.Data.DataRowCollection>. (A row in this state does not have a corresponding original version since it did not exist when the last <xref:System.Data.DataRow.AcceptChanges%2A> method was called).|  
+|<xref:System.Data.DataRowState.Deleted>|The row was deleted using the <xref:System.Data.DataRow.Delete%2A> of a <xref:System.Data.DataRow> object.|  
+|<xref:System.Data.DataRowState.Detached>|The row has been created but is not part of any <xref:System.Data.DataRowCollection>. A <xref:System.Data.DataRow> object is in this state immediately after it has been created, before it has been added to a collection, and after it has been removed from a collection.|  
+|<xref:System.Data.DataRowState.Modified>|A column value in the row has changed in some way.|  
+|<xref:System.Data.DataRowState.Unchanged>|The row has not changed since <xref:System.Data.DataRow.AcceptChanges%2A> was last called.|  
 
 ### DataRowVersion enumeration  
  Datasets maintain multiple versions of records. The <xref:System.Data.DataRowVersion> enumeration of a <xref:System.Data.DataRow> object is a value that can be used to return a specific version of a <xref:System.Data.DataRow> object.  
@@ -146,10 +146,10 @@ Two-stage update process and the role of the DataRowVersion in a successful upda
 
 |DataRowVersion Value|Description|  
 |--------------------------|-----------------|  
-|<xref:System.Data.DataRowVersion>|The current version of a record contains all modifications that have been performed on the record since the last time <xref:System.Data.DataRow.AcceptChanges%2A> was called. If the row has been deleted, there is no current version.|  
-|<xref:System.Data.DataRowVersion>|The default value of a record, as defined by the dataset schema or data source.|  
-|<xref:System.Data.DataRowVersion>|The original version of a record is a copy of the record as it was the last time changes were committed in the dataset. In practical terms, this is typically the version of a record as read from a data source.|  
-|<xref:System.Data.DataRowVersion>|The proposed version of a record that is available temporarily while you are in the middle of an update — that is, between the time you called the <xref:System.Data.DataRow.BeginEdit%2A> method and the <xref:System.Data.DataRow.EndEdit%2A> method. You typically access the proposed version of a record in a handler for an event such as <xref:System.Data.DataTable.RowChanging>. Invoking the <xref:System.Data.DataRow.CancelEdit%2A> method reverses the changes and deletes the proposed version of the data row.|  
+|<xref:System.Data.DataRowVersion.Current>|The current version of a record contains all modifications that have been performed on the record since the last time <xref:System.Data.DataRow.AcceptChanges%2A> was called. If the row has been deleted, there is no current version.|  
+|<xref:System.Data.DataRowVersion.Default>|The default value of a record, as defined by the dataset schema or data source.|  
+|<xref:System.Data.DataRowVersion.Original>|The original version of a record is a copy of the record as it was the last time changes were committed in the dataset. In practical terms, this is typically the version of a record as read from a data source.|  
+|<xref:System.Data.DataRowVersion.Proposed>|The proposed version of a record that is available temporarily while you are in the middle of an update — that is, between the time you called the <xref:System.Data.DataRow.BeginEdit%2A> method and the <xref:System.Data.DataRow.EndEdit%2A> method. You typically access the proposed version of a record in a handler for an event such as <xref:System.Data.DataTable.RowChanging>. Invoking the <xref:System.Data.DataRow.CancelEdit%2A> method reverses the changes and deletes the proposed version of the data row.|  
 
  The original and current versions are useful when update information is transmitted to a data source. Typically, when an update is sent to the data source, the new information for the database is in the current version of a record. Information from the original version is used to locate the record to update.  
 
@@ -184,7 +184,7 @@ You can commit the pending changes to the dataset by calling the <xref:System.Da
 -   After you load the dataset. If you load a dataset by calling a TableAdapter's `Fill` method, then the adapter automatically commits changes for you. However, if you load a dataset by merging another dataset into it, then you have to commit the changes manually.  
 
     > [!NOTE]
-    >  You can prevent the adapter from automatically committing the changes when you call the `Fill` method by setting the `AcceptChangesDuringFill` property of the adapter to `false`. If it's set to `false`, then the <xref:System.Data.DataRow.RowState%2A> of each row that's inserted during the fill is set to <xref:System.Data.DataRowState>.  
+    >  You can prevent the adapter from automatically committing the changes when you call the `Fill` method by setting the `AcceptChangesDuringFill` property of the adapter to `false`. If it's set to `false`, then the <xref:System.Data.DataRow.RowState%2A> of each row that's inserted during the fill is set to <xref:System.Data.DataRowState.Added>.  
   
 -   After you send dataset changes to another process, such as an XML Web service.  
 
@@ -193,11 +193,11 @@ You can commit the pending changes to the dataset by calling the <xref:System.Da
   
 This method accomplishes the following:  
 
--   Writes the <xref:System.Data.DataRowVersion> version of a record into its <xref:System.Data.DataRowVersion> version and overwrites the original version.  
+-   Writes the <xref:System.Data.DataRowVersion.Current> version of a record into its <xref:System.Data.DataRowVersion.Original> version and overwrites the original version.  
 
--   Removes any row where the <xref:System.Data.DataRow.RowState%2A> property is set to <xref:System.Data.DataRowState>.  
+-   Removes any row where the <xref:System.Data.DataRow.RowState%2A> property is set to <xref:System.Data.DataRowState.Deleted>.  
 
--   Sets the <xref:System.Data.DataRow.RowState%2A> property of a record to <xref:System.Data.DataRowState>.  
+-   Sets the <xref:System.Data.DataRow.RowState%2A> property of a record to <xref:System.Data.DataRowState.Unchanged>.  
 
 The <xref:System.Data.DataSet.AcceptChanges%2A> method is available at three levels. You can call it on a <xref:System.Data.DataRow> object to commits changes for just that row. You can also call it on a <xref:System.Data.DataTable> object to commit all rows in a table. Finally, you can call it on the <xref:System.Data.DataSet> object to commit all pending changes in all records of all tables of the dataset.  
 
@@ -212,7 +212,7 @@ The following table describes which changes are committed based on what object t
 > [!NOTE]
 >  If you load a dataset by calling a TableAdapter's `Fill` method, you don't have to explicitly accept changes. By default, the `Fill` method calls the `AcceptChanges` method after it finishes populating the data table.  
   
- A related method, `RejectChanges`, undoes the effect of changes by copying the <xref:System.Data.DataRowVersion> version back into the <xref:System.Data.DataRowVersion> version of records. It also sets the <xref:System.Data.DataRow.RowState%2A> of each record back to <xref:System.Data.DataRowState>.  
+ A related method, `RejectChanges`, undoes the effect of changes by copying the <xref:System.Data.DataRowVersion.Original> version back into the <xref:System.Data.DataRowVersion.Current> version of records. It also sets the <xref:System.Data.DataRow.RowState%2A> of each record back to <xref:System.Data.DataRowState.Unchanged>.  
 
 ## Data validation  
  In order to verify that the data in your application meets the requirements of the processes that it is passed to, you often have to add validation. This might involve checking that a user's entry in a form is correct, validating data that's sent to your application by another application, or even checking that information that's calculated within your component falls within the constraints of your data source and application requirements.  

docs/data-tools/validate-data-in-datasets.md

@@ -192,7 +192,7 @@ Validation can also be performed during the <xref:System.Data.DataTable.RowChang
      [!code-vb[VbRaddataEditing#17](../data-tools/codesnippet/VisualBasic/validate-data-in-datasets_5.vb)]  
 
 ## Access the original version of a DataRow  
- When changes are made to data rows, the dataset retains both the original (<xref:System.Data.DataRowVersion>) and new (<xref:System.Data.DataRowVersion>) versions of the row. For example, before calling the `AcceptChanges` method, your application can access the different versions of a record (as defined in the <xref:System.Data.DataRowVersion> enumeration) and process the changes accordingly.  
+ When changes are made to data rows, the dataset retains both the original (<xref:System.Data.DataRowVersion.Original>) and new (<xref:System.Data.DataRowVersion.Current>) versions of the row. For example, before calling the `AcceptChanges` method, your application can access the different versions of a record (as defined in the <xref:System.Data.DataRowVersion> enumeration) and process the changes accordingly.  
 
 > [!NOTE]
 >  Different versions of a row exist only after it has been edited and before it the `AcceptChanges` method has been called. After the `AcceptChanges` method has been called, the current and original versions are the same.