Se criarmos um pequeno modelo do banco de dados Northwind, e tentar modificar um dos registro de customer ("ALFKI" por exemplo):
NorthwindDataContext db = new NorthwindDataContext();
Customer alfki = db.Customers.Single(c => c.CustomerID == "ALFKI");
alfki.City = "London";
db.SubmitChanges();
Veremos que a query de atualização gerada em tempo de execução foi:
UPDATE Customers
SET City = 'London'
WHERE CustomerID = 'ALFKI' AND
CompanyName = 'Alfreds Futterkiste' AND
City = 'Berlin' AND
Region IS NULL
Evidentemente, a query de atualização da coluna cidade SET está de acordo com a coluna CustomerID, mas quem são estas condições, na cláusula where?
LINQ para SQL usa Optimistic Concurrency estratégia. Quando os registos são selecionados, não realizar qualquer lock sobre as linhas selecionadas. Só quando ele tenta atualizar os registros no banco de dados ou excluí-los é que ele verifica se os mesmos não foram alterados desde a última consulta. Como é feito? Ele tenta atualizar a linha que coincide com os valores originais, contido no DataContext. Isto explica as condições adicionais na query de atualização.
Se durante a execução a lógica foi finalizada, as atualizações que forem feitas a partir de outro programa (ou outro DataContext), lançara uma exceção:
System.Data.Linq.ChangeConflictException was unhandled
Message="Row not found or changed."
Source="System.Data.Linq"
LINQ para SQL tenta olhar para o registro atualizado e comparar com todas as colunas com seus valores originais, e quando não encontra o registro, a exceção é lançada. Essa é a maneira que o LINQ para SQL nos diz que a linha que estava procurando foi eliminada ou alterada por outro programa e a atualização não pode ser feita.
Artigo originalGuy Burstein's
Comentários