If you are using Entity Framework, this is one of the most common and often misleading errors you will see. There are several possible explanations for this error that may lie in the code or in the database. Here are a few reasons for this error and how to resolve them.
You are attempting to access data and the database connection is closed.
ObjectContext is the base class you inherit from when you generate entities from entity framework. It handles several tasks, most significantly opening and closing the database connection, writing and executing queries.
If you instantiate your ObjectContext in a using block, the connection is closed at the end of that block.
First off, be aware that retrieving data is a two step process of writing and executing SQL, even though it’s hidden away and often written in one line. Any code that attempts to access the database must be executed within the using block.
If retrieving an IEnumberable with a query, wrap in a .ToList() to force data loading.
For navigation properties of an entity, use Include(), or call entities.Load(). You must check the .IsLoaded property of any navigation property to see if it’s there. You can’t check if the property is null or it may attempt to access the database.
Also note that even within an entity context, you must call .Load() before calling .Clear() to delete navigation properties from the database. Failing to do so won’t cause an exception but it will fail to delete the data. Also be aware that calling .Load() on a detached entity will cause the next error…
Your entity is not Attached.
This is just a variation of the previous issue. If you already have an entity before instantiating your context, they are not associated just because you are in a using block. Therefore, if you attempt to access navigation properties of that entity, you will get this error because the system assumes the entity came from a context which is now closed.
Call ObjectContext.Attach(entity) before attempting to access the entity navigation properties. Note: calling Attach can cause other errors which I will address in a separate post.
Another reason is missing navigation entities (a.k.a orphan data). This is the most likely cause if the bug only occurs when requesting specific data, or if you step through your code and the bug occurs within a loop, but not on the first iteration.
Navigation properties are based on foreign keys. If the foreign key points to a row that does not exist, you have an orphan child row. This can occur if the entity is deleted or updated but the foreign key is set to do nothing. Check your data and try setting the FK action to cascade or set to null.
If the navigation property is nullable, you much check if it is null before accessing any property. This sounds like common sense but it is very easy to forget.
Also, check the table mappings of your parent entity. If your parent entity has any mapping conditions (ex. ‘When ActiveFlag = true ), any rows that don’t match the condition will be excluded from the data sets gathered by entity framework. They will be treated as if they were deleted from the database. This will essentially make your child rows orphaned data, but without the safety net of the foreign key violation. Be very cautions with exclusionary table mappings on parent rows.
edmx file is out of sync with the database. This issue can occur any time you change a table or column name in the database and forget to update your model. It is even more likely when multiple developers are working off a shared database.
Open your edmx file. Right-click anywhere in the white space and select ‘Update Model From Database’. Select ‘validate’ from the same menu. This will find many issues but some will pass through compile and only get caught at run time. If you have made extensive changes to an entity, it’s often easier and safer to simply delete it from the edmx and add it again. This will reset the names of all your properties but it will ensure they match the database names, which is usually the best route for clarity.