Develop Reference

Entity Framework Core Database First

My team has inherited a database application that contains hundreds of tables. The application uses Entity Framework and takes a database first approach for development. Our current process is to pull a table or two at a time into the edmx using the Update Model From Database... tool.
We are considering making a new API with .Net Core, but as far as I can tell from the research I have done, there is no equivalent process in the Entity Framework Core tools. The closest thing I can find is to reverse engineer the entire database with Scaffold-DbContext, and then use migrations for all future database changes. We can't scaffold the entire database, because some of the tables have errors, and fixing all those errors is not a viable option for us right now.
I have found that I can supply a list of tables that I want scaffolded with the initial Scaffold-DbContext call, but I'm not sure if migrations can be used in a similar way to the Update Model From Database... tool. Can I use migrations to add tables that already exist in our database? If not, what other options should I be looking at?

Ado.net data entity model EF 6.x taking freezing on Wizard

I have been using ADO.NET Entity Data Model Ef 6.x database first with different MS SQL Server databases and it has been working alright until I've got a prod local copy of production database schema having a lot of tables. I'm not doing anything fancy rather just trying to add DbContext with the standard wizard. For some reasons, it is taking ages and never successfully creates DbContext and entity models. It takes insane amount of time even when I try to select one single table out of whole lot of tables but it at least successfully creates DbContext. I need to create DbContext for pretty much every table within the database. Any thoughts how can I generate that using ADO.NET entity data model EF 6.x?

Following SQL script resolved my problem.
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION=ON
Once you generate DbContext running the above script you should turn that back off
with the following script
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION=OFF

Migrating data from 2 different SQL Server databases using console app

I have 2 web applications which are let's say Legacy1 and New1. I have separate DbContext for both applications and separate databases.
Now I want to migrate data from the Legacy1 database to the New1 database. I cannot simply use copy database or export database options in SQL Server. Entities are different and I need to incorporate some logic while migrating data.
I have decided to use .Net Core Console (.Net Framework) project to do this. Do I have to add both DbContexts to this project? Also all the entities which I want to map and do the migration or is there any other way to achieve this.

Finally i found a simple approach to achieve that. I used EF DB First approach to generate edmx files for source and target databases. Which gives me access to corresponding Entities as well.
I Queried source database using source dbcontext and manipulated data as per the requirements and inserted into target database using target dbcontext. I used AutoMapper to map source entities to Target entities.
It was much simpler than i thought earlier. Hope it helps others having similar scenario.

Does NHibernate have a feature to Create and Update Tables, like EF Code First does Automatic Migrations?

I am using NHibernate and Fluent NHibernate for the first time. I had to physically create the database and write SQL scripts for the first 2 tables. Now, i am wondering if this technology (NHibernate), like Entity Framework (Code First) when you have enabled migrations has a similar too to create and update tables?
This is what i mean by Ef Code First Automatic Migrations

nHibernate does support schema changes using SchemaUpdate
See: Is NHibernate SchemaUpdate safe in production code?
You can also generate a create script to execute against your database using nHibernate SchemaExport.
SchemaUpdate is not recommended for production use because of the security privileges that have to be granted in order for this to work. Personally I think you should look at a code based migrations tool which are designed to handle initial database creates plus full revision control, I use Migrator.NET - Database migration in C#

Entity Framework Code First on external SQL server

I'm following the Entity Framework tutorial on:
Link
I've downloaded the source code, and ran. The project works fine (using the default connection string).
<add name="SchoolContext" connectionString="Data Source=|DataDirectory|School.sdf" providerName="System.Data.SqlServerCe.4.0" />
Next i've changed the connection string to connect to a remote server (which successfully connects). However the tables aren't created and when running the application and accessing the controller I get the following error.
Error:
Model compatibility cannot be checked because the database does not contain
model metadata. Model compatibility can only be checked for databases created
using Code First or Code First Migrations.
My database user is 'dbowner' so I wouldn't imagine it's database access issues.
I'm new to EF, and don't know much about Code First Migrations. Have you come across the above error, and would Code Migrations solve this issue? If so why?

From my reading (please correct me if I am wrong) the scenario here is that you have an existing (perhaps empty) database on a remote server that you wish to put your EF code-first work into.
The error is coming about because, I think, EF is looking for a _MigrationHistory table (metadata about what EF code-first migrations have been run against it etc) and can't find it. There is some reasonable coverage of this table here for some background/interest reading.
So to resolve the issue, I think the steps to take are:
Initialise your database so that it acknowledges the EF code-first stuff
Update the database, rolling forward all your migrations to date
I found some good coverage of how to do this here. This blog also has some good coverage of EF topics in general
PS. I am guessing that your .dsf/SQL Compact Edition database wouldn't have had this problem because EF code-first would have created it for you on first run so it was already acknowledged as being a code-first database.

Here is a link to Entity Framework Power Tools. It is made for creating models by 'Reverse Engineering' your Database on a remote server. You can then easily access this database using EF.
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database

Both of the initializer methods which I had tried fail when the database already exists:
Database.SetInitializer<Context>(new Initializer());
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<Context>());
However it is possible to force the database to be dropped using:
Database.SetInitializer(new DropCreateDatabaseAlways<Context>());
The following SO post provides the answer to my question:
Setting up a Entity Framework Code First Database on SQL Server 2008
I've tried a combination of the two, and have decided that the best solution is to manually go into SQL Management studio and DROP the database, and re-create it using the initializer as this allows me to Seed the contents of the database.
Database.SetInitializer<Context>(new Initializer());
See here for more information on Seeding the database as it is also quite an unstable processess!
How can I get my database to seed using Entity Framework CodeFirst?