Nota: puede actualizar a EF 4.1 o 4.2 que hace que este trabajo fácil como un amuleto:
context.Entry(myEntity).State = EntityState.Unchanged;
Por favor refiérase a this para el detalle.
Crear una clase parcial a su ObjectContext clase generada, e incluyen los métodos siguientes en el mismo (VB, lo siento - se debe transcribirse fácilmente a C#):
Public ReadOnly Property DirtyObjects() As IEnumerable(Of ObjectStateEntry)
Get
Return ObjectStateManager.GetObjectStateEntries(
EntityState.Added Or
EntityState.Deleted Or
EntityState.Modified)
End Get
End Property
Public Overloads Sub Refresh()
For Each entry In DirtyObjects
Select Case entry.State
Case EntityState.Modified
Dim original = entry.OriginalValues
For Each prop In entry.GetModifiedProperties()
Dim ordinal = original.GetOrdinal(prop)
entry.CurrentValues.SetValue(ordinal, original(ordinal))
RaisePropertyChanged(entry.Entity, prop)
Next
entry.AcceptChanges()
Case EntityState.Deleted
'I think I would need to call the above again, cuz it might be
'changed values on a Deleted-state entry too.
entry.ChangeState(EntityState.Unchanged)
Case EntityState.Added
entry.ChangeState(EntityState.Detached)
Case Else
'do nothing
Debug.Fail("It's not supposed to stop here.")
End Select
Next
End Sub
Heads up! En la nueva versión venidera, esta característica se ha vuelto muchísimo más fácil.
Sí, me di cuenta demasiado tarde ... pero el problema es que si eliminas el contexto del objeto e intentas conectar la base de datos, el rendimiento es demasiado malo. Así que decidimos mantener vivo el contexto Object. Intentando encontrar una manera de revertir los cambios en caso de falla. – Bhuvan
@Bhuvan: esa afirmación de que "el rendimiento es malo" generalmente significa que está solicitando demasiados datos. He hecho ** montones ** de trabajo donde el contexto de datos tiene un alcance muy estrecho y está perfectamente desarrollado. –