I'm using Entity Framework 5 model first. Say I've deployed the application and I'd like to upgrade an EF entity with new columns, basically adding columns to the table.
What is the best way to upgrade the existing database without losing data? For example I have a User table that I add two new columns to. If I try to script a schema change the tables will need to be dropped in order to add the new columns. Is there a way to update the tables without needing to recreate them? Thanks!
This may be a late answer but I have had the same problem and could just find one solution, there is an application that can update the model-first generated databases without losing the data.
It can directly open the model file and update the database tables.
It also installs some extensions on Visual Studio that I have not personally used but may be usable.
The name is Entity Developer and there are some editions of the application listed here:
Entity Developer Editions
The free edition is usable only for 10 entities or less that may not suit your needs but the Professional edition is usable for 30 day as a trial that may help you do the job. The only solution I could find on the net was this one.
Hope it helps you with the problem.
Related
I have two different applications (two different solutions) using the same database. Each application has its own set of models/tables used in it.
The .NET solution for Application 1 was created a year back and has evolved till today. As part of this, some new models were created, migrations were added and updated in the database (SampleDatabase). This has its own DBContext class.
The .NET solution for Application 2 is a new one created a month back. This application also uses the same database (SampleDatabase). A few new models specific to this application were created, migrations were added and updated in the database. This has its own DBContext class.
Requirement:
Now, there is a requirement where one of the tables created and being used by Application 1 needs to be modified to integrate with Application 2 (i.e., a PK from an Application 2 table has to be placed as a FK in an Application 1 table.).
Challenge
To create a migration for altering the model from Application 1, a reference is needed to the PK table available in the other solution, which is not possible.
To create a migration for altering the existing model from Application 2, the existing model has to be copied to the Application 2 codebase. By doing so, if a migration is added, it generated only a CreateTable statement and not an alter as the DBContext does not know that the table already exists.
Question:
How do we manage to have migrations that is aware of things happening in the database from both the solutions?
Thoughts:
One way that I had in mind is to have a shared library project that can be responsible for all migrations to this database. Requirements for any application can be taken care by this project. But this has to refer the DBContext from both the application which is again a challenge.
Please let me know your thoughts and if anyone has faced such situation in your projects.
Thank You.
I have read multiple posts about this but do not have a clear answer yet.
We are transitioning to EF Core 2.0 company-wide, one project at a time.
The challenge is this:
A new project starts and a database is created using code first, migrations etc.
another programmer needs to create a project targeting the same database.
This programmer can use Scaffold-DbContext and generate current models.
However, a new column is needed and this second programmer adds it.
Now...how do we best update the other projects?
Is there something that checks and syncs or shows what is out of sync between your model and a database? Meaning check the database for changes...not the model.
We don't mind buying a tool if that is the best solution.
The solution we have been using, very successfully is the Database project in Visual Studio.
Using that each developer has the project in their solution, changes are made against it locally.
Then we can do a "Schema Compare" inside of VS.
We have been using this successfully for 4 of us the past three weeks extensively with almost no issues.
This has even worked for keeping versions and changes to our stored procedures current.
It works well with VSTS also.
Here are some of the posts I read that helped me understand it:
https://www.sqlchick.com/entries/2016/1/10/why-you-should-use-a-ssdt-database-project-for-your-data-warehouse
https://weblogs.asp.net/gunnarpeipman/using-visual-studio-database-projects-in-real-life
..and this forum had a lot of relevant questions/answers:
https://social.msdn.microsoft.com/Forums/sqlserver/en-us/home?forum=ssdt
Is there a more elegant way to maintain a view in Model-First Entity Framework? There's plenty of discussion regarding how to do this using Migrations in Code-First, but of course Migrations are not available when using Model-First.
My current approach:
Run "Generate Database from Model..."
Run the created script
Delete the table EF generates for the view
Create the view manually
The last two steps are done in a post-script, of course.
I'm not expecting an integrated view-designer (although I think that's what MS was originally intending for future releases, before they fell in love with Code-First). For example, if it's possible simply to tell EF not to create that table, it would be a small improvement.
I got an existing database with many tables which are accessed using stored procedures only (no O/RM). I'd like to create new tables in this database using Entity Framework and the Code First approach.
Do all the tables in my existing database need to be modelized in my Entity Framework classes? Will I be able to hand-code only the new classes I need in my DbContext? Other tables really need to stay untouched and away from O/RM for the moment.
Note: I'm going to be using the latest EF5.
As for now the Power Tools only allow you to reverse engineer all tables and views in the DB, which can be a problem if you have a big DB, with hundreds of objects, you do not want to reverse engineer.
However, I found an easy workaround for that:
Create a new technical user for the reverse engineering. To this user you only grant permission to the tables and views, that you want to be reverse engineered.
Have fun!
You are under no obligation to map any given table with EF. If you already have a database, you may want to consider reverse-engineering your database with the EF Power Tools available from Microsoft. I did this recently with a MySQL database that I had for testing purposes and it worked quite well!
If you are new to EF an advantage is that the PowerTools write a ton of code for you, which will help you get a grasp on the syntax of Code First. You will need to modify the output but it is a great start. I really believe that this approach will give you the least headache.
The EF PowerTools can be found here: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
I am trying to add tables from an existing Advantage Database (recently upgraded from v8 to v10) to a .NET project via the Entity Framework. However, no matter what I do, the relationships between the tables are not being imported from the database. Obviously, I can just recreate them in Visual Studio, but I'd prefer to keep the data structure primarily in the database.
This link describes the problem, but the solution (permissions issues) doesn't work for me. We're using the IGNORERIGHTS security mode in connections, and user permissions are not enabled on the database.
Based on this chapter, I've made sure that the tables in question are ADT tables, and have Primary keys which are non-nullable. I've also verified that the RI constraints exist and show up in Advantage's visual designer.
Despite all that, when I "Update Model from Database" in the EDMX and select the tables which have a reference between them, no reference is created.
Is there anything else I can try? Some step I'm missing? A setting that needs to change?
I ended up deleting the EDMX for entirely unrelated reasons, and when I recreated it, relationships worked just fine. It's quite possible that Mark's suggestion was the answer, but for new ones only. I didn't do any extensive testing to try and confirm that, though.