Off topic, how did you enjoy the bike races?
>>Entity framework internally caches entities it retrieves in its object graph, which means you won't see changes... until you dump the context or explicitly reload.
>>
>>There are a couple of ways around this.
>>
>>I see you're using MergeOption.OverwriteChanges which *should* actually be enough to force the query to be re-loaded. But apparently that's not working for you?
>
>I don't think that query does remove an entity that has been deleted on disk (which, arguably, it should )
>
>>The easiest is probably to make sure you always query on a new DbConecxt instance. Make sure you recreate a new context rather than re-using an existing context.
>>
>>Another option is to use context.Entry(entity).Reload() which forces an individual entity to be reloaded from disk.
>
>Interesting to know whether Reload() would work.
>
>>Depending on your scenario the latter can be more efficient as it's actually just requerying a single record not the whole set.
>
>Would using MergeOption.NoTracking have the same effect as using a new Context ?
>
>>+++ Rick ---
>>
>>>I am currently testing an application using EF4.3 containing pre-compiled queries.
>>>
>>>
>>> mqryClientByID = Function(ctx As FGLMainDataEntities, pID As Integer)
>>> Return (ctx.Clients.
>>> Include("EMails").
>>> Where("it.ID = " + pID.ToString()
>>> ).Execute(MergeOption.OverwriteChanges).SingleOrDefault())
>>> End Function
>>>
>>>
>>>This basically get a client's data and his related email addresses.
>>>
>>>I just found that if I modify the emails directly in SSMS (simulating another user modifying records), I can see the modification whenever I re-execute my query with:
>>>
>>>
>>>Dim currentClient = mqryClientByID.Invoke(mobjContext, pID)
>>>
>>>
>>>But if I delete email addresses related to a client and I reload the client, the row is still shown in the grid.
>>>
>>>How can I tell EF to refresh data for real?