Chris,
The behavior can be linked back to your ForeignKeyConstraint object. You set its
AcceptRejectRule property to Cascade. When a DataAdapter submits a pending change in
a row, it implicitly calls the AcceptChanges method on the row if the update attempt
succeeds. By setting the AcceptRejectRule property to Cascade, you're cascading that
call to AcceptChanges to the related child rows as well.
Setting AcceptRejectRule to Cascade is helpful in a some scenarios, such as when
you want to submit pending deletions and the back end will cascade that change down to
related tables. However, it's probably not what you wanted for your scenario. The
default for the property is None, which is what you probably want. The default value
means that the call to AcceptChanges will not cascade down to the child rows.
When submitting changes to multiple tables, your best bet is to submit pending
inserts and updates against the parent table, then submit the pending changes in the
child table, then submit the pending deletes against the parent table. You can use
the DataTable's Select method to submit just the desired changes using code like:
ParentAdapter.Update(ParentTable.Select("", "", DataViewRowState.ModifiedCurrent Or _
DataViewRowState.Added))
ChildAdapter.Update(ChildTable)
ParentAdapter.Update(ParentTable.Select("", "", DataViewRowState.Deleted))
(I know in your case you're not dealing with pending deletions at the parent level,
but this is just a generalization)
I'm not a big fan of using GetChanges to isolate inserts vs. updates vs. deletes
because it creates a separate copy of the data, which means that after you've
submitted your updates, you have to go back to the original copy of your data to get
it back in synch. This process can get rather hairy if you're working with pending
inserts that generate new auto-increment values on the server. The Select method
returns an array of DataRow objects, which are basically pointers to the original rows
rather than separate copies.
I hope this clears things up a little. There's more information on the
scenario in Chapter 11 of "Microsoft ADO.NET" from Microsoft Press.
David Sceppa
Microsoft
This posting is provided "AS IS" with no warranties,
and confers no rights. You assume all risk for your use.
© 2002 Microsoft Corporation. All rights reserved.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
