I am having problems saving database records using Linq in visual studio 2010 and sql server 2008.
My problem is that when I am editing some records I sometimes check the original database record for validation purposes, only the original entry seems to be updated in real time – I.e. it is already exactly the same as the edited record, before I have submitted the changes!
Could anyone suggest an effective method of coping with this? I have tried using a 2nd database connection or a 2nd data repository to call the original record from the db but it appears to be already changed when I debug it.
public void SaveobjectEdit(object objectToEdit)
{
object originalObject = GetobjectById(objectToEdit.Id);
if (originalObject.objectStatus != objectToEdit.objectStatus)
{
originalObject.objectStatus = objectToEdit.objectStatus;
}
SaveChanges();
}
The save changes just calls _db.SubmitChanges(); by the way
Has no one got any ideas for the above question?
I hope I was clear – for validation purposes I would like to compare an original database record with one that I am editing. The problem is that when I edit a record and then attempt to retrieve the original record before saving – the original record is exactly the same as the edited record.
If you’re trying to retrieve the original record in code, from the same ‘context’ using the same access method, then it will contain the updated object. Rather than ask why you’re doing this or what you’re trying to achieve, I’ll instead explain how I understand the data context / object context to work (in a very loose and vague fashion).
The context is something like an in-memory representation of your database, where everything is lazy-loaded. When you instantiate the context you’re given an object which represents your data model (of course it may not be a 1-1 representation, and can contain various abstractions). Nothing is loaded into the context until necessary; any queries you write stay as queries until you peer in their results. When you access an item (e.g.
GetobjectById(objectToEdit.Id)) the item is loaded into the context from the database and you cangetandsetits properties at your leisure.Now, the important part: When you access an item, if it has already been loaded into the context then that in-memory object is returned. The context doesn’t care about checking changes made; the changes won’t be persisted to the database until you submit, but they remain in memory.
The way to refresh the in-memory objects is to call the
Refreshmethod on the context. Try this test:I believe this pattern makes a lot of sense and I’m not sure it could work any other way. Consider this:
Would you want the
Assertto fail? Should those items be reloaded? I don’t believe so. I’m looking at the items in my context, not in the database. I’m not checking whether items in the database have been updated, but instead that I’ve updated all the items in the context of my code.This is a good reason why I don’t use
MyObjectContext db– it is not a ‘db’ or a database connection. It’s a context within which I can change whatever I want, so I name it such:MyObjectContext context.