Aspetta...
ma è perfettamente normale, ed è giusto che sia così.
quando modifichi una proprietà di una entity questa viene marcata come modified, ma solo quella. quando riesegui la query LINQ lui la esegue per eventualmente re-idratatre i campi che tu non hai toccato in precedenza, ma al contempo salvaguardia quella che tu hai modificato.
Questo è il lavoro dell'ObjectTracker, ovvero quello di tenere traccia delle modifiche alle singole proprietà delle entity nell'ObjectContext.
Inoltre la questione della concurrency non rientra minimamente nelle query in lettura, ma solo per quelle di update, quindi abilitare la concurrency per una proprietà non influisce quando si vanno a leggere i dati.
in questo senso il meotodo Refresh con StoreWins si occupa proprio di imporre la reidratazione della entity con i valori del db.

saluti

dal mio punto di vista è semplicemente il modo con cui EF lavora, overo, hanno deciso che di default ClientWins, e che se voglio forzare il reload dal db devo espressamente dirlo. è una decisione come un'altra, potevano fare il contrario, ma a mio avviso sarebbe stato pericoloso perchè avrebbe significato che le modifiche apportate nella UI venivano perse di default, e questo è scocciante per l'utente, invece in questo modo se voglio cancellare le modifiche effettuate sulla entity devo volerlo in utlima istanza e procedere ad una chiamata ben precisa. stesso discorso se cmq nel frattempo il db è stato modificato da terzi (insomma è sempre meglio preservare le modifiche apportate in memory che sono per loro natura volatili senza dover ricorrere a entity di appoggio clonate).
D'altra parte bisogna anche considerare che di default EF ragione in termini di LastWins dal punto di vista delle concurrency e che quindi in questo senso il fato che un terzo abbia nel frattempo modificato quel particolare campo è del tutto ininfluente perchè cmq verrà sovrascritto con una update, motivo per il quale non ha senso caricarlo dal db in caso abbia modificato in memory la proprietà corrispondente.
Invece se viene attivata la concurrency è corretto a mio avviso che l'eventuale modifica di terzi e la mia in memoria scateni un'eccezione solo in scrittura e non in lettura, perchè è lì che la logica di business decide se brutalmente ricaricare dal db, se invece sovrascrivere o se caricare una nuova entity con i dati presenti nel db e proporla all'utente a confronto con quella che lui stava cercando di salvare (e lasciando a lui la decisione di che cosa fare).

saluti
Roberto

Il comportamento che hai descritto e dovuto alla proprietà MergeOption dell'ObjectQuery. Fai un cast invece che su IQueryable<T>, su ObjectQuery e cambia questa proprietà. Puoi scegliere se sovrascrivere ciò che hai fatto o disabilitare il tracking.

La riesecuzione della query è una cosa che va al di là del tracking. Se hai un IQueryable tenuto in una variabile e lo consumi più di una volta questo viene sempre rieseguito e per il semplice fatto che non puoi prevedere che la medestima query ti dia sempre lo stesso risultato, anche se hai fatto un filtro per chiave (potrebbe non esserci più nel db). Sei troppo fiducioso verso i computer, non sono così intelligenti
Non a caso MergeOption di default è AppendOnly che singnifica che i nuovi record restituiti dalla query vengono presi dal db, mentre quelli già nel sistema di tracking vengono mantenuti.

---

Modificato da Ricciolo il 14 settembre 2008 18.06 -