I am using EF6 with existing db and a separate new schema for my code first.
We were moving from staging to Production, and suddenly realized that all db's code first objects were gone, all beside the migration table.
Of course everybody blamed code first as the cause. Is it possible? or maybe someone deleted the objects manually by mistake?
In my Static Context constructor I used
Database.SetInitializer(new MigrateDatabaseToLatestVersion
Related
Good day guys,
I noticed my application deletes database structure and re add new one everytime i Run my application.
The DBset uses DropCreateDatabaseIfModelChanges. I have read about the other options like CreateDatabaseIfNotExist. is there any other option to force it from recreating database?
And also with throwing any exception of error?
I have been able to resolve this by using Code First Migrations
I have accidentally deleted data from __MigrationHistory table and I tried to make migration new tables and column changes to db. At this time EF6 show me an error
"There is already an object named 'xxxx' in the database.".
I tried the way by using this command and there is no effect on table column changes.
Add-Migration MyMigration1 -IgnoreChanges
Update-database -Force
There are many recommendation about this for recreating db or another else. But those ways might be effect data losing to my db which contains a huge size of tested data and I can't able to lost any data. How to solve this error by without losing any data. If anybody please...
Update
Finally I found the solution to solve my problem. I am not sure it's a prefer way to solve such kind of problems but it's worked for me.
I cleaned data from __MigrationHistory table,tried to migrate new db and I copied data from __MigrationHistory of new db to my old db, then I set AutomaticMigration true and run update-database command and the problem was solved.
I'm not sure if its good approach to fix that but it worked for me.
I just did insert into that table with proper version and names of the already applied migrations, I did it in EF Core and it works actually, but please wait for somebody to comfirm that what im writing about.
The problem I see there is that you need two more fields to be filled (in EF Core theres only two columns) but I think that you can receive them using for example SQL Profiler
I'm running into a frequent MVC DB first issue where everytime I update my domain model classes from the DB, something always seems to be breaking. In this case, after adding another table and model into my project, running Update model From Database and Generate Model From DB in the .EDMX file, a perfectly good table with a working query is causing the Invalid Object Name error when the app runs in the browser.
I've cleaned and rebuilt my project multiple times. Everything compiles and the error only occurs when the app tries to run in the browser.
Is DB First prone to being buggy or am I not doing something properly when using DB first approach?
Error Screens
I created the databases first, then used the wizards in Entity Framework 5 to create the models from the Database first. Over time, through development, I made changes to the models and let EF recreate them by deleting my database and then starting the project up and they magically appeared again with the changes I made to the columns . It worked great on SQL Express 2014. But Godaddy doesnt let EF do that, AND I have databases with names like "Hazards.Models.CompanyDataContext" that EF made and didnt ask me what I wanted to name them. How do I change the code so it will let me rename the database it uses, and if possible, incorporate it into the aspnetdb that mvc uses as an additional table (there already is simplemembership etc. in there.)?
Seeing as you used EF database first, rather than deleting your database and letting EF recreate it, have you thought about doing it the other way round?
You could use something like management studio express to rename your database tables/columns however you see fit. Then in Visual Studio, open your .edmx file, right-click the background and select 'update model from database'. This way you can add new tables to the model or update the models of existing tables from the database. Better still, you can take care of it all outside of godaddy.
Note: I found that when updating the EF model, just updating existing tables gives odd results sometimes. It's much more reliable when you delete tables from your .edmx first, then right-click and select 'update model from database', and add the tables back to your model.
I have an ASP.NET MVC 3 app that is using SQL Server CE 4.0 and Entity Framework 4.1 Code First. It works fine locally, but in production, it fails with the following error:
The model backing the 'foobar' context has changed since the database was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer instance. For example, the DropCreateDatabaseIfModelChanges strategy will automatically delete and recreate the database, and optionally seed it with new data.
I've verified that my application dll and database file are up-to-date on the remote server, but I continue to get this error.
Any idea what the problem could be?
Note: I'm using the RTF version of the Entity Framework 4.1, not CTP.
Edit
Okay, if I delete the EdmMetadata table, and re-publish the database to the production server, I no longer get the error. However, I completely don't understand why I should have to do this. The model has not changed. It hasn't changed in weeks, and I rebuilt the database just today. I guess the key to this whole thing is the hash. What is the EdmMetadata hash being compared against?
Edit 2
According to Mark S's answer, the hash in the EdmMetadata table is compared against a hash of the SSDL. However, there is no actual SSDL file (no file with extension .ssdl and no file containing "ssdl") anywhere in the solution. So, where is the SSDL actually stored? Is it generated at design time or run time?
Edit 3
To answer my own question, SSDL does get generated and cached at runtime (more details here), but looking at the actual schema of SSDL, I'm not sure I see anything that could possibly change simply because the project's DLL lives in a different location on a different server.
Note: I'm using the exact same database file (.sdf) for test and production. I'm literally ftp-ing the file from bin/App_Data to the App_Data folder on the production server. I'm also ftp-ing the project DLL. So, the only thing that should be different between test and production is that these files live in a different place.
Also, just for the record, here is my connection string:
DataSource=|DataDirectory|foobar.sdf" providerName="System.Data.SqlServerCe.4.0
Edit 4 (final edit?)
The problem turned out to be a DLL issue. I think a different version of the EntityFramework DLL was being used remotely vs. locally. The solution was to make sure I had the latest version of EF 4.1 (RTW), clear and re-add references, regenerate the database, and re-publish. Everything is now working great.
In response to "What is the EdmMetadata hash being compared against?"
The EdmMetadata table allows Code First to determine if the model in your code is the same as the model in your database. The table contains a single row which is a hash of your SSDL. SSDL stands for Store Schema Definition Language and is an XML based language used to describe an Entity model and the mappings between models.
You can read more about SSDL and view the specification at http://msdn.microsoft.com/en-us/library/bb399559.aspx
You mention that things work fine locally but not in production. Are you allowing Code First to build both the local and production databases? Is the production database already existing or being generated in another fashion?
CodeFirst is reporting that the hash in the database doesn't match the present model's hash so something must be different. Figuring out what may be a challenge.
The EdmMetadata table is mapped to the EdmMetadata class. There is a TrygetModelHash method in this class which you can use to get the hash for a given context. If you're desparate you could use this to compare your current model to the hash that's in your production database. This would at least keep you from having to build a new database constantly just for testing.
You can also instruct Code First to exclude the EdmMetadata table if desired.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove<IncludeMetadataConvention>();
}
Disable validation:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove<IncludeMetadataConvention>();
}
Check out this video:
http://www.pluralsight-training.net/microsoft/players/PSODPlayer.aspx?author=scott-allen&name=mvc3-building-data-i&mode=live&clip=0&course=aspdotnet-mvc3-intro
This is part of the free plural sight training available on http://asp.net/mvc. Click the "When Classes Change" video on the left side of the page, then go to 8:30 in the video.
Apparently if you delete the EDMMetadata table in the DB, EF will disable model validation.