Every so often, I run into an "entity is out of sync with its data..." exception when I have a bound entity collection to an infragistics ultra grid. It happens after I save and I was wondering if this sounds like possibly the problem. After the save entity method is complete, the foreign keys are synced up by the LLBL runtime, therefore a change event is raised and the grid tries to refresh it's contents. So when this happens, it gets an "entity out of sync" exception. Does this sound right to anyone?

MarcoP wrote:

Every so often, I run into an "entity is out of sync with its data..." exception when I have a bound entity collection to an infragistics ultra grid. It happens after I save and I was wondering if this sounds like possibly the problem. After the save entity method is complete, the foreign keys are synced up by the LLBL runtime, therefore a change event is raised and the grid tries to refresh it's contents. So when this happens, it gets an "entity out of sync" exception. Does this sound right to anyone?

Are you refetching after save in the DataAccessAdapter SaveEntityCollection call?

No, I b/c I am on an edit form and when the user saves the entity (recursive) the screen is closed.

MarcoP wrote:

No, I b/c I am on an edit form and when the user saves the entity (recursive) the screen is closed.

From what I understand, the saved entity (and entities that point to it?) is considered out of sync if they are not refetched after a save. You would have to pass RefetchAfterSave = true to the SaveEntityCollection call (or SaveEntity, whichever one you use) to avoid this. Its a bit annoying, but LLBLGEN just doesn't know if the save triggered data changes, so it needs to refetch the data.

Hmm....but the thing is, is that the exception is not thrown everytime a save takes place, but every so often. I thought maybe under the hood, when the foreign keys are synced up after a save, the binding events are not raised. Maybe frans well look at this

MarcoP wrote:

Hmm....but the thing is, is that the exception is not thrown everytime a save takes place, but every so often. I thought maybe under the hood, when the foreign keys are synced up after a save, the binding events are not raised. Maybe frans well look at this

Binding events are raised in that situation, but if I understand correctly, you don't need the bindinevents as the form is closed. So something doesn't add up.

Also, exceptions have stacktraces, so where does the call originate from?

Correct, I do not need the binding events after a save since the edit dialog is closed. Here is part of the stack trace:

Exception Info: The entity is out of sync with its data in the database. Refetch this entity before using this in-memory instance.

Exception Stack Trace: at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.GetCurrentFieldValue(Int32 fieldIndex) at Touchstone.CRM.DL.EntityClasses.IncidentEntity.get_AssignedOnDate() at Touchstone.CSD.CRM.Incident.Views.IncidentEditViewPresenter.SaveIncident(Boolean close)

I'm assuming the grid is trying to pull the assigned on date value out of the entity. So is it safe to say whenever you have two-way databinding in-place and you need to save an entity, you need to refetch after the save? There is really no events I can unsubscribe to since it happens within the grid control itself.

MarcoP wrote:

Correct, I do not need the binding events after a save since the edit dialog is closed. Here is part of the stack trace:

Exception Info: The entity is out of sync with its data in the database. Refetch this entity before using this in-memory instance.

Exception Stack Trace: at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.GetCurrentFieldValue(Int32 fieldIndex) at Touchstone.CRM.DL.EntityClasses.IncidentEntity.get_AssignedOnDate() at Touchstone.CSD.CRM.Incident.Views.IncidentEditViewPresenter.SaveIncident(Boolean close)

I'm assuming the grid is trying to pull the assigned on date value out of the entity. So is it safe to say whenever you have two-way databinding in-place and you need to save an entity, you need to refetch after the save? There is really no events I can unsubscribe to since it happens within the grid control itself.

Thats pretty much how I understand it. I think if you use a BindingSource object to bind to your grid, you can set yourBindingSource.RaiseListChangedEvents to False and this will prevent the entities Changed events from trickling up to the grid control which causes the grid to read the bound entities again (which ends up throwing that exception).

MarcoP wrote:

Correct, I do not need the binding events after a save since the edit dialog is closed. Here is part of the stack trace:

Exception Info: The entity is out of sync with its data in the database. Refetch this entity before using this in-memory instance.

Exception Stack Trace: at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.GetCurrentFieldValue(Int32 fieldIndex) at Touchstone.CRM.DL.EntityClasses.IncidentEntity.get_AssignedOnDate() at Touchstone.CSD.CRM.Incident.Views.IncidentEditViewPresenter.SaveIncident(Boolean close) I'm assuming the grid is trying to pull the assigned on date value out of the entity. So is it safe to say whenever you have two-way databinding in-place and you need to save an entity, you need to refetch after the save? There is really no events I can unsubscribe to since it happens within the grid control itself.

In SaveIncident, you're reading AssignedOnDate, which is out of sync, please check that code in SaveIncident()