Under what circumstances would a LINQ-to-SQL Entity "lose" a changed field?
- by John Rudy
I'm going nuts over what should be a very simple situation. In an ASP.NET MVC 2 app (not that I think this matters), I have an edit action which takes a very small entity and makes a few changes. The key portion (outside of error handling/security) looks like this:
Todo t = Repository.GetTodoByID(todoID);
UpdateModel(t);
Repository.Save();
Todo is the very simple, small entity with the following fields: ID (primary key), FolderID (foreign key), PercentComplete, TodoText, IsDeleted and SaleEffortID (foreign key). Each of these obviously corresponds to a field in the database.
When UpdateModel(t) is called, t does get correctly updated for all fields which have changed.
When Repository.Save() is called, by the time the SQL is written out, FolderID reverts back to its original value. The complete code to Repository.Save():
public void Save()
{
myDataContext.SubmitChanges();
}
myDataContext is an instance of the DataContext class created by the LINQ-to-SQL designer. Nothing custom has been done to this aside from adding some common interfaces to some of the entities.
I've validated that the FolderID is getting lost before the call to Repository.Save() by logging out the generated SQL:
UPDATE [Todo].[TD_TODO]
SET
[TD_PercentComplete] = @p4,
[TD_TodoText] = @p5,
[TD_IsDeleted] = @p6
WHERE
([TD_ID] = @p0) AND
([TD_TDF_ID] = @p1) AND /* Folder ID */
([TD_PercentComplete] = @p2) AND
([TD_TodoText] = @p3) AND
(NOT ([TD_IsDeleted] = 1)) AND
([TD_SE_ID] IS NULL) /* SaleEffort ID */
-- @p0: Input BigInt (Size = -1; Prec = 0; Scale = 0) [5]
-- @p1: Input BigInt (Size = -1; Prec = 0; Scale = 0) [1] /* this SHOULD be 4 and in the update list */
-- @p2: Input TinyInt (Size = -1; Prec = 0; Scale = 0) [90]
-- @p3: Input NVarChar (Size = 4000; Prec = 0; Scale = 0) [changing text]
-- @p4: Input TinyInt (Size = -1; Prec = 0; Scale = 0) [0]
-- @p5: Input NVarChar (Size = 4000; Prec = 0; Scale = 0) [changing text foo]
-- @p6: Input Bit (Size = -1; Prec = 0; Scale = 0) [True]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 4.0.30319.1
So somewhere between UpdateModel(t) (where I've validated in the debugger that FolderID updated) and the output of this SQL, the FolderID reverts. The other fields all save. (Well, OK, I haven't validated SaleEffortID yet, because that subsystem isn't really ready yet, but everything else saves.)
I've exhausted my own means of research on this: Does anyone know of conditions which would cause a partial entity reset (EG, something to do with long foreign keys?), and/or how to work around this?