Any idea on how we might accomplish this on the server side using the Web API? Currently, we are using AfterSaveChangesDelegate to reload or load navigation properties, including the entity that is being updated. However, there are numerous forums that state that context cannot live long and are not meant to live long for that matter. There are suggestions that the original DbContext should be disposed and create another one. While that can be accomplished, we don't see how that is going to work with Crosslight's Enterprise design through the AfterSaveChangesDelegate. Disposing the original context also means that any change tracking behind the scene will stop. The solution provided by Arief in this thread does work at times in simple scenarios where a trigger is simple enough that the results of an updated row are refected in an instant. However, most of the triggers that we have require complex calculations that updating the expected results of a row or record might be delayed at some point; thus, it might make sense the the navigation properties are updated on the second time an entity is being saved from the client-side. That being said, we can't save the same data twice from the client-side in order to get the updated data for a navigation property.

Although triggers should be synchronous in nature, and calling SaveChanges in a DbContext should have triggered the changes of the affected rows. We don;t understand why the reload or load methods of the entity functions are unable to retrieve an update record for the navigation properties attached to the entity that has been saved. Any solutions or workarounds would be very much appreciated. Thanks!