I have an edmx file and I changed a table in my database. I know that there is an "Update Model from database" wizard, however in many cases this is useless.
For example if I change a field from non null to nullable or if I remove fields the update model does not reflect the changes. I have had to remove the entity and add it back in to get the changes to appear in my model.
Per the following question: How do I propagate database changes to my .edmx file?
One of the answers seems to say the same thing, that you need to remove the entity and add it back in.
Is this the definitive answer or is there a better way to do this?
An important first step is to understand exactly what happens when you use the update model wizard.
From the MSDN Library:
The ADO.NET Entity Data Model Designer (Entity Designer) uses the Update Model Wizard to update an .edmx file from changes made to the database. The Update Model Wizard overwrites the storage model as part of this process. The Update Model Wizard also makes some changes to the conceptual model and mappings, but it only makes these changes when objects are added to the database. For example, new entity types are added to the conceptual model when tables are added to the database, and new properties are added to entity types when columns are added to a table. For details about what changes are made to the .edmx file, see Changes Made to an .edmx File by the Update Model Wizard.
When you updated the database using the update model wizard, it updated the storage model in the .edmx file and not the conceptual model. When changes are made to the definition of existing objects, only the storage model is updated; the conceptual model is not updated. For a complete description of changes that are made by the update model wizard, please see the "Changes Made to an .edmx File by the Update Model Wizard" link above.
Here are some options on how to update objects that are not updated by the update model wizard (based on your scenario where a the column definition was altered):
The best option would depend on the given scenario. For example, if you just altered the definition of one column, then option 1 is likely you best choice. If you altered the definition of a number of columns in a single table, then option 3 might be your best choice. If you altered a column that is used across a number of tables (such as a primary / foreign key), then editing the .edmx XML directly might be your best option.
As you have found, the update from database does not always change existing properties correctly.
From our day-to-day use of EDMX updating (100s of updates over 24 months), I would recommend the following sequence for updating an EDMX.
This will obviously lose any manual tweaks you have made to the model, but manual tweaks are to be avoided if possible. This makes the entire process reproducible at any time (which is a good thing).
Keep your EDMX in a separate library. This also becomes a great place to add additional TT files and partial classes (e.g. to extend function of EDMX models). I also place any extension methods for the database context in this library. The
migration files get generated in the library too keeping it all nicely contained.
The latest Release 4 of Visual Studio 2013 appears to have resolved a lot of the TFS issues. We now see Visual Studio checkout generated files, then revert them if they are unchanged. The above steps still appear to be the safest approach.
Using latest VS2013 Release 5, we still have issues if a save occurs during EDMX update. You can still wind up in a state where pending deletes causes your
tt files to be removed from source control during the update. The secret is to update fast between steps 4 and 5! :)