I'm using the DataSet
/DataTable
/DataAdapter
architecture to mediate between the database and my model objects, which have their own backing (they aren't backed by a DataRow). I've got a DataAdapter
with AcceptChangesDuringFill = False
, AcceptChangesDuringUpdate = False
, and FillLoadOption = OverwriteChanges
. Here's my understanding of the DataAdapter
model under these conditions:
DataRowState.Added
will result in the InsertCommand
firingDataRowState.Modified
will result in the UpdateCommand
firingDataRowState.Deleted
will result in the DeleteCommand
firingDataTable
will be used to update that row, and that row's state will always become DataRowState.Modified
, even if the returned row is identical to the current rowDataRowState.Added
DataTable
that doesn't correspond to a row in the returned result set will stay at DataRowState.Unchanged
Given that I'm correct with this mental model, suppose I want to use Fill()
to notice deleted rows in the data source. Also, suppose that the parameters of the SelectCommand
don't return the entire table. I'm guessing that I have two options:
Fill()
but are still DataRowState.Unchanged
(relies on my untested italicized assumption above). These rows have been deleted at the data source.DataTable
before the Fill()
; any row that doesn't show up again has been deleted at the data source. This loses the distinction between DataRowState.Added
and DataRowState.Modified
that is preserved with the first method.So, my questions:
DataAdapter
correct, subject to the property values I noted at the top?DataRowState.Modified
even if the row is identical; is that a safe assumption?Turns out that my assumption is erroneous—if a row returned by the SelectCommand
is exactly the same as a row already in the DataTable
, that row remains marked as DataRowState.Unchanged
. So the proper procedure is removing rows from the DataTable
before calling Fill()
, and determining the fate of a row by comparing the new set of DataRowState.Added
rows to the former list of rows.