I've been experiencing a lot of weird things with the Entity Framework designer in visual studio 2015 Professional. If I try to updated the model from the database it will delete all of the mappings of existing entities and replace the mappings with only the one I updated. If I add a relationship to existing entities it will delete all existing entity classes. The only way to update anything in the designer is to write it all out in XML.
Am I doing something wrong or is there something wrong with the file integrity maybe? I've found workarounds that say I have to completely delete the model and redo it from the database every time if I want to make a change. Updating the Model from the database. Even with this the auto-mapping isn't correct.
It shouldn't be this difficult, that's why I'm lead to believe that maybe something in the files that is making it lose it's integrity after copying it from the previous developer. Or is something else maybe the culprit?
What fixed it was instead of deleting the entire model from the project, I just deleted the Entities from the designer and recreated the entire model from the database. What threw me off when I tried this was it brought in some new fields that weren't in the model before and some table names had changed.
Related
For some reasons we need to update Views inside the Entity Framework.
So we followed this solution on another question and it worked like a charm!
BUT here is the problem:
if we update our model (for some new fields or tables/views) the complete Mappings are destroyed and after updating we get the Warning
Error 11007: Entity type 'UpdateView1' is not mapped.
After this it's not even possible to load the entities because all Mappings are lost.
So how to design the views to be able to post updates using the Views AND to be able to update the edmx file?
MS is dropping support for EDMX files going forward in Entity Framework - in part due to the difficulty of keeping the database, EDMX, and POCOs all sync'd, as you are experiencing. (Anyone can edit any of the 3, then changes are lost when a sync is done).
So they recommend using the Code First approach. Code First is a bit of a misnomer and causes some confusion.
Code First doesn't mean you have to start with code.
You can start with the database and then write your POCOs to match it (as in your case). Doing so allows you to preserve all your mappings and such because you just adjust your code to match the structure already present in your database.
Another misconception is that you have to use migrations. You do not. You are welcome to not enable migrations and manually edit both the database schema and POCOs as long as you ensure they remain in sync.
The situation: Sometimes a database schema is not what you would consider an ideal representation of the system's information and you may not be able to change it. We have been using Entity Framework to create a nicer conceptual model to code against in situations like this. This means updating the model from the database and then changing it ourselves, either through the designer or through the .edmx file directly using a text editor.
The problem: When you update the model from the database, all your carefully made changes are thrown out the window. This can make adding new entities a real hassle as you are basically forced to do it through editing the .edmx file directly.
The question: Is there a way to get the Entity Framework to only update selected entities from from the database? Or is it possible to tell it to leave the rest of the model alone when adding a new entity?
Thanks!
No there is no way to make selective updates with built-in designer. Also the designer doesn't throw away all your changes. It usually doesn't touch conceptual model (except some rare occasions where it continuously renames some associations) and mapping but it always deletes storage model and override it with new definition. I worked without any problem with modifications to my conceptual model and mapping and running updates from the database.
Designer works as any other in Visual Studio - touching the generated code (storage model) is not supported feature. Once you do it you cannot use Update from database anymore.
There is commercial tool which probably supports better model updating - you can try a trial.
If by updating selected entities, you mean just one or more tables, you can delete those tables from the model, and then add them back in individually to pull in changes tables by choosing them individually - I do that often as underlying tables are changed (especially during development).
You do end up losing any manual changes you made to those re-added entities after the entity/table was pulled into the model (i.e. I often rename my navigation properties and then after each re-import of the table I need to manually rename them again).
I am using Entity Framework code first for the first time in a production environment. Everything went fine until we got the DB up and had put some of the data in it and then to get some of the data we were importing from another location we had to change field lengths. So we made some of the fields nvarchar(99) instead of nvarchar(50).
That went fine and the application still worked but I knew I needed to change the data annotation or it would blow up later when it loaded and tried to save a too long field. When I did that the app blew up even though the model and the db are now matching. So I thought that it was the hash in the metadata table so I thought I'd be clever and make a new DB and take the hash from there and copy it. That did not work and in fact now I cannot get my app to connect to the test db that we have data loaded in at all.
I do not want to drop and recreate this database. I want entity framework to realize that the model and the schema do in fact match. Is there any way for me to do this? Also why did copying the metadata from a DB that entity framework created with this model not work?
Entity Framework Code First creates a EdmMetadata table and saves a hash of your Model classes in it. When you change something in the Model, the hash of the new Model classes doesn't match what's in the EdmMetadata table anymore, and the app should "blow up" at runtime. What you need to do to keep using the same database without dropping it, is to delete the EdmMetadata table. This way EF will not do that check and will try to proceed with the access to the DB.
Check this video tutorial (skip to 8:10 of the "When Classes Change" section).
Sorry I fixed this. Removing the metadata worked. But turns out I had updated to a more recent version of EntityFramework accidentally while trying to fix my problem and this more recent version expected different naming conventions for the Database. In any case recreating the many-to-many group person table with a script from a DB created by Entity Framework and deleting the metadata fixed the problem.
I have been updating my Entity Framework by simply right clicking and clicking on "update model from database". I usually go under the "Add" tab and then click the tables and click finish. I also use "refresh" sometimes as well. What are the differences between these? and also when I do refresh or add sometimes the entity comes out wrong or keeps some of the old information in cache, how can I just get the entity to match my database and clean out any of the old cached things.
Yes, you are right. The designer is a bit buggy and doesn't handle certain schema changes particularly well. As a rule, when I add a table to the database, I run Update model from database and select the table in the Add tab. Works fine. If I add a field to an existing table, I do Update model and Refresh. Works well too.
But if I add one field and remove another, or rename an existing field (as far as I remember), EF does not handle this correctly (added a new field but failed to remove the old one, and since the old one remained unmapped, the model validation failed). So in those more complex cases I usually delete the entity and then do Update model from database and Add it again.
The downside is that if you did make some changes (e.g. renamed some fields or navigational properties of the entity), you'll have to do those changes again.
It doesn't clean out old items. You have to delete those yourself. On the positive side, Visual studio will give you an error when you compile, stating that a coloumn or two isn't mapped. The entity framework tool is more of a code generator. It generates classes based on the structure of your database, as opposed to being tied to the database for is't structure information.
Designer is not buggy and the reason why it doesn't handle some changes is because CSDL and some MSL modifications made by user are not overwritten. CSDL is the diagram you see in designer and MSL is the mapping of your entities and associations.
Believe me this is a big step forward comparing to Linq-to-sql where no update existed and you always had to delete everything including your changes when you wanted to refresh your model. If you made a lot of changes you can always delete your entity in EF designer as well. EF designer offers a choice to update or recreate (by deleting the old one).
I've got a pretty large DB hooked up to my Entity Framework. I've got one particular set of tables where a common key (fk) was deleted from the design. When I "update the model from the database", I get a series of errors about this now-missing key.
Why doesn't the update process accurately detect that this key was removed? Also, if I manually remove the property from the model, I just end up with other errors. I also tried to simply delete the table and re-add it, but now the table doesn't show up in the "Add" section of the update wizard.
So, short of deleting the entire thing and starting over, is there any way to recover gracefully? Has the EF team released any newer versions of this wizard that has some of these issues fixed in it already?
Entity Framework does get confused from time to time. What you need to do is delete the Entity Table from the model, then rename the table in SQL Server to TableName_Temp, refresh the model, now the Entity Table should be OK, so delete the entity table again rename it back to the original name and refresh the model once more. This time everything should be fine.
I know this is a messed up procedure but this is the only way I found to fix this issue without blowing away the entire edmx and starting from scratch. Currently at my organization we have a policy not to make changes to the EDMX unless absolutely necessary so that we can delete and recreate when ever needed without any problems.
Hope this helps!