In mySql Workbench there's a possibility to "sync" the model with the DB and vice versa. Is there a function like this in EF? I've added som entities and I'd like it to get reflected in the DB. Do I really have to regenerate the entire DB and loose data?
Thanks
Sadly there is no easy way AFAIK to do this today.
One way to handle this is to generate the DDL and then cut and paste the new sections into SQL Server Management Studio and run them there. If you want to maintain scripts for each release of the database you'll need to take an approach like this too.
See also: Database migrations for Entity Framework 4
PS The EF Power Pack: http://msdn.microsoft.com/en-us/data/ff830362.aspx may help. It says "The second useful feature related to model-first the ability to update an existing database and synchronize the model with it. This allows you to make changes to the model that can be deployed to the database without data loss."
if you are using the VS2010 then in Select your edmx designer ( designer showing tables) and right click it will show the update model option.
Related
I have this edmx model (see below) and I would like to add an extra association from Order to Worker *-1 as shown by the red line, problem is, the database has already got lots of data that I don't want to wipe, is it possible to add do this without recreating the tables?
Simply let EF to create a new database in your development environment and use some database diff. tool to get change script from the old database to a new one. VS 2010 Premium and Ultimate contains this diff. tool and you can even use it directly from EDMX designer if you install Database Generation tools power pack.
Another popular diff tool is for example SQL Compare by RedGate.
Just because you have used Entity Designer to start with doesn't mean that you have to totally recreate your database each time.
If you generate the SQL from your changed model, you should be able to find the part referring to your new relationship easily enough. That is the only part you need to run against your database- just split it out into it's own file. If in doubt save a copy of the old SQL file, add your relationship, generate the new file and create a diff to be sure.
Alternatively if you have a good understanding of how EF represents data and relationships you can probably change the database manually. As long as the database and the model are accurately coherent, EF doesn't really care how the database got that way.
I developed a website using EF 4.1 code first,Mvc3 ,Sql Sever 2008 r2, and deployed it.
The database on the host got filled with critical data and it still grows.
Now I want to add new columns to different tables and also add new tables.
Even if I back up my SQL and bring it to the development environment and using base.seed() or even create a script using SQL server management I will lose data and I have tried different way and I couldn't find a way which I wouldn't lose data.
I looked at code first migration and it didn't solve my problem. My team added some tables to database using SQL server management and if I use code first migration it wont pick the changes that occurs manually. someone suggested that using reverse engineering tools that would create code first from database but this also makes many unwanted code.
What is the best way or best practices for changing database using code first approach?
Migrations will help you. You just need to script current database and recreate it in your environment. Then you need to add empty initial migration to use your current database as a starting point. You will then add all new tables and columns and let migrations do their job. Sure there can be problems because you have manually changed the database in the production but that is your team's failure in the first place because it violates code first development approach. If this was supposed to happen you should not use code first approach.
As alternative simply develop new version of your application with new tables and columns, create database from your application in your development environment and use database tools for schema compare either in VS 2010 (Premium or Ultimate) or in another commercial tool like Red Gate Compare. This will be able to create diff SQL script for upgrading old DB schema to a new one.
For EF 4.1 you have the Code First Migrations available as a Nuget-package, that let's you migrate you database as your models change.
As of EF 4.3, Migrations is now included in Entity Framework.
The ADO.NET team has blogged about how to get started with EF 4.3 Migrations.
Building and maintaining a database that is then deplyed/developed further by many devs is something that goes on in software development all the time. We create a build script, and maintain further update scripts that get applied as the database grows over time. There are many ways to manage this, from manual updates to console apps/build scripts that help automate these processes.
Has anyone who has built/managed these processes moved over to a Source Control solution for database schema management? If so, what have they found the best solution to be? Are there any pitfalls that should be avoided?
Red Gate seems to be a big player in the MSSQL world and their DB source control looks very interesting:
http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm
Although it does not look like it replaces the (default) data* management process, so it only replaces half the change management process from my pov.
(when I'm talking about data, I mean lookup values and that sort of thing, data that needs to be deployed by default or in a DR scenario)
We work in a .Net/MSSQL environment, but I'm sure the premise is the same across all languages.
Similar Questions
One or more of these existing questions might be helpful:
The best way to manage database changes
MySQL database change tracking
SQL Server database change workflow best practices
Verify database changes (version-control)
Transferring changes from a dev DB to a production DB
tracking changes made in database structure
Or a search for Database Change
I look after a data warehouse developed in-house by the bank where I work. This requires constant updating, and we have a team of 2-4 devs working on it.
We are fortunate because there is only the one instance of our "product", so we do not have to cater for deploying to multiple instances which may be at different versions.
We keep a creation script file for each object (table, view, index, stored procedure, trigger) in the database.
We avoid the use of ALTER TABLE whenever possible, preferring to rename a table, create the new one and migrate the data over. This means that we don't have to look through a history of ALTER scripts - we can always see the up to date version of every table by looking at its create script. The migration is performed by a separate migration script - this can be partly auto-generated.
Each time we do a release, we have a script which runs the create scripts / migration scripts in the appropriate order.
FYI: We use Visual SourceSafe (yuck!) for source code control.
I've been looking for a SQL Server source control tool - and came across a lot of premium versions that do the job - using SQL Server Management Studio as a plugin.
LiquiBase is a free one but i never quite got it working for my needs.
There is another free product out there though that works stand along from SSMS and scripts out objects and data to flat file.
These objects can then be pumped into a new SQL Server instance which will then re-create the database objects.
See gitSQL
Maybe you're asking for LiquiBase?
Can you create a database diagram for a database and save it without creating the actual tables? You know, so the boss can check it out before you apply it?
No. The database diagram is somewhat confusingly named in that it is basically a table designer not just a pictorial representation of the database.
Saving the diagram will persist all changes to the underlying database objects.
Not if you're setting keys/relationships. When you make those connections in the diagram, SSMS establishes the keys/constraints as well.
If your boss wants to look at a diagram before you make the changes, I would suggest Visio or some other visualization tool. You can provide the same information (albiet with a little extra effort) and it doesn't mess with the DB itself. Addtionally, you'd then have a "database diagram" which was disconnected from the DB, so if you wanted to make future changes, you could move things around with impunity until you got your connections/relationships just the way you want them.
No, but why don't you print it out and show it to your boss like that
ideally you have a dev version of the database where you make changes and this won't impact anything
You could use a tool like SQL Dependency Tracker to visualise your database, or you could just make a copy of your database schema and save your databse diagram in SSMS on the copy if you don't want to apply them to the original instance.
I have a Microsoft Access 2010 database(*). Now, using Visual Studio 2010, I want to create a WPF application and add the database as a data source. The app will have a window with a frame that provides navigation through pages. No problem so far. But:
-What is the right way to set up the database in this scenario? Tables only? Or must everything go via queries? (VS2010 talks about views which I assume (?) are queries)
-Database data must be updatable and records can be added. Some relationships go through link tables (many-to-many) and there are nullable foreign key relationships. Must I take manual steps to make it work?
-While adding the data source VS2010 created an xsd from my Access database. I think the xsd might need further tweaking for the application to work the right way. What if I change my Access database design, I'd have to regenerate the xsd again as well. Is this right, and is it the way it is usually done? OR, should I let the original Access database go and give the application the capability to create new empty databases?
-How do you provide controls in a page to step through the records in a table? Is there a special database control?
-What is the way (WPF class?) to load records into the data context that displays in a page? (At this level it probably does not matter what type of data source it is.)
(*) A single user desktop database
This is not the exact answer to the question. But an alternative.
Is this a single-user database?
You can try this better and highly efficient combination:
SQLITE (DataBase)
DBLINQ (ORM)
LINQ(a .NET framework component for querying the db)
You should also take a look at ObservableCollection, DataBinding and DataGrid in WPF toolkit.