• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 134
  • Last Modified:

How should I handle objects that Entity Framework doesn't want to update?

I have a few related newbie questions about Entity Framework. (I'm using Entity Framework, according to Web.config, and using a "database first" approach).

1) If I change an object in the database (e.g., rename a column in a table or change the output columns of a stored procedure), and then in Visual Studio I select "Update model from database" and "Refresh," the object changes still aren't reflected in Entity Framework.  (Unlike with the "Add" tab, the "Refresh" tab doesn't let one select what to refresh, so it's hard to know if it's doing anything when I click Finish, plus the code never works if I rely on the "Refresh.")  So my workaround is to create the same object with a different name.  E.g., if I had a database object called "item," then I simply create a clone of it in SQL Server named "item1," and then I can add it to EF. That works.  So my question is, how do I get EF to work without renaming my database objects every time I want to change them?  I don't want to be stuck with so many versions of the same objects.

2) Why are "Result" objects (e.g., the results of stored procedures) not even shown in the diagram?  It seems that the only way to update these, if I make changes in the database, is to open edmx's XML and edit that manually.  Is there a better way?

3) Since EF stopped writing to Context.cs (even for new objects), I started writing entries directly there. I also noticed that running "custom tool" overwrites the other cs files, but not Context.cs, which is kind of good, because I was able to do things I don't think EF would have been able to create automatically.  But seeing that Context.cs is *supposed* to be auto-generated (even though it isn't in my case), I'm wondering if editing it is bad practice.  Should I be defining the same partial class in a separate file and then put any custom entries there?  That leads to the following issues though:

3a) Does it matter where I put such a file?
3b) If auto-updating of EF stuff *did* start to work again, wouldn't my customized entries duplicate ones that are auto-generated?  Or is EF smart enough not to create duplicate definitions?
3c) Or is it better practice to just use regular ADO.NET for anything slightly complicated?

4) Overall, what is the best way to "clean up" Entity Framework and have it just work "normally"? And, apart from avoiding manual changes (which I wasn't even doing at first), what is the best way to prevent it from getting into a weird state in the first place (e.g., weird state = a state where one has to run "custom tool" to have it create any classes, and where it doesn't put anything into context.cs)?
  • 4
1 Solution
Najam UddinCommented:
Do you hit save after refersh? If still does not work, you can manually remove and add things.
To remove,
a. delete object from <DBName>_DataModel.edmx -->  <DBName>_DataModel.Context.tt --> <DBName>_DataModel.Context.cs --> *Entities --> Find your object and delete it
b.  <DBName>EntitiesPartialClass.cs -> *Entities --> Find your object and delete it

Once you do this you issues should be fixed.
NewbisAuthor Commented:
Thanks...I did figure out that I have to keep hitting save in between, but that didn't help me with the specific updating problems mentioned above.  I'll try your suggestion about manually deleting "bad" objects and see if it helps.
NewbisAuthor Commented:
Anyhow, deleting in all those different places, so I can re-add something is still just a workaround...and it doesn't explain why updating doesn't work...what, is the update tab just there for decoration?

And now I notice that if I change a table structure and make all the changes in EF to fit the change in the table, adding a row through EF fails silently!  And I have SQL Profiler open (which seems to be the only practical way to know what EF is doing, as using reflection seems overkill just to see what query was generated), and EF sends nothing...nothing at all!  So if one adds and removes a column, and updates everything in EF accordingly, the linkage to that table is lost forever.

So the only way, really, to do any add operations in a way that can still work if one changes the table structure  is to have a stored procedure for every table, just to do an insert operation.

I never realized that EF is so batty!
NewbisAuthor Commented:
So the solution to this problem basically is to "run custom tool" on the various locations where that option exists, several times, in between doing a "save all" (ctrl-shift-S), and to create a separate file outside EF for any custom or manually-created methods, using the same namespace and partial class, and giving a different name to those methods than what EF would create.
NewbisAuthor Commented:
Never got a clear answer to why EF behaves like this, but at least I've worked around it.  The worst thing you can do though is to delete any files in EF if you're connected to Team Foundation Server.  ...because then, EF will recreate those files, but they can never be checked in again.

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now