They're two entirely different things. Note how SaveOptions
has the Flags
attribute: this indicates you can combine multiple flags, in this case to make SaveOptions.AcceptAllChangesAfterSave | SaveOptions.DetectChangesBeforeSave
.
And if you're wondering about something like SaveOptions.None | SaveOptions.AcceptAllChangesAfterSave
, then keep in mind that SaveOptions.None
is the zero value, so this is just a long-winded way of writing SaveOptions.AcceptAllChangesAfterSave
.
So you use SaveOptions.None
when you want neither SaveOptions.AcceptAllChangesAfterSave
nor SaveOptions.DetectChangesBeforeSave
.
Can any of these option, in any way, be used to reverse the changes made by objectContext.SaveChanges()
?
In the context? If you don't include SaveOptions.AcceptAllChangesAfterSave
, then all changes will be preserved locally as unsaved. All added entities will remain in "added" state, all modified entities will remain in "modified" state, all deleted entities will still be available by explicitly requesting your context's deleted entities. Attempting to save again will likely fail, as the database has already been updated. You can then use the regular methods for reverting unsaved changes, but it requires a lot of manual work on your part, it requires manually looking up the original values of all properties and restoring that value. A detailed example of how to do this is, I think, beyond the scope of this question, but see Undo changes in entity framework entities.
In the database? This requires even more work on your part, and may not even be possible at all: once an entity with a server-generated column (e.g. auto-increment key, or row version field), it is generally impossible to restore it with those exact same values it originally had.