linq-to-sql implementing a business model wrapper for row level change rollback

[MaslowB]

Is there a recommended way to implement individual row-level change tracking? such that when a change is made to more than one row before a save is called, changes that the database doesn't reject move forward, the ones that don't aren't? I have am trying to figure this out for two projects a ticketing database, and an asset management database.

Say the user wants to change one asset from being an asset with no subtype to being a workstation asset. The database would reject this change without the additional required non-nullable workstation information. The user also filled out a completely new asset form which would save just fine. Using direct databinding for the controls. I now have a row which should be able to save its changes, and one that can not. Because of how linq-to-sql works neither change can be saved now.

[jmcilhinney]

The IEditableObject interface exists for this purpose. Consider the DataRow and DataRowView classes. The DataRow does not support transactional editing, while the DataRowView does through its implementation of the IEditableObject interface. You would need to do something similar. You would need to define your own type that implemented IEditableObject and provided a view of your L2S entities.

[MaslowB]

So far I've defined my own superclass, with the IEditableObject interface,then turned off the IEditableObject interface so that the damn bindingSource didn't automatically try to save everytime the user navigated. I was hoping to see if there were any other best practices or objects in .net I didn't know about that make this step a little less work, like a way to use the dbml to generate a dataView or dataRowView.