Develop Reference

How to delete data in dependent tables in a .NET application when EF Core is used with no tracking?

I am using EF Core code-first approach and this time I used records instead of classes for the database models. So I had to disable tracking and instead of using navigation properties I defined models for linking tables for many to many relations and used foreign keys for one to many relations.
Since EF Core didn't generate ON DELETE CASCADE statements for foreign keys, I have to find a way to delete data from dependent tables when deleting data from entity tables.
What would be the fastest approach? Since I use repositories, I can update the Delete methods to also call Delete methods for other entities. I can alter the migration code generated by EF to define foreign keys and add ON DELETE CASCADE. I can add the same constraints straight to the database. Somehow I don't like the last two approaches, because it makes creating and adding new entities harder.
If I use the Delete from repository approach, is the following a reasonable idea?
get the name of current entity
get all mapped entities from the context
use reflection to get the members of the entities and see if any
matches "Current entity name" + "Id"
delete all matching records

How to add nonclustered indexes in Entity Framework db-first project?

I have a table in SQL Server which includes custom nonclustered indexes for some columns. And I have also a project with below versions.
.Net Framework 4.6.2
Entity Framework 6.4.4
I added an entity data model to project based on my existing database (using a database-first approach).
Although a SELECT query returns quickly in database, the same query gets a timeout error in the project. And I thought that EF couldn't add
column indexes to the project. I searched index names in the project,
but there isn't any code about indexes in the project.
So, how can I add indexes to my database-first model?

So, how can I add indexes to my database-first model?
"database-first" means that you apply design changes to the database first, and then apply any changes to the EF model second.
So you just create the indexes in SQL Server using Visual Studio or SSMS, and since EF model doesn't need to change when you add an index, you're done.

Deleting columns from Database doesn't give a mistake in project

So there's an ASP.Net project that uses Entity Framework Core. Of course, there are Entities classes, Configuration Entities classes, etc. And there are properties in Entities that map some table's columns. Also there is connection string to connect to database. The thing I don't get: I deleted some columns from database table. But project builds and everything is fine. What do I miss? I though that mistake should be given because Entity properties don't map table columns...

A successful build has nothing to do with working code. If you remove columns from the database the project builds, since the project does not have information about the database structure. But as soon as you query for the table where the columns have been deleted, then the code should throw exceptions. I suggest you not to modify the database directly, but read into the topic of EF migrations so that modifying the model updates the database.

Entity Framework 6 add existing complex type to key columns

I'm working on a project using EF 6 built using database-first approach. There are several tables that previously had the same 3 properties mapped to a complex type (used in several places throughout code). These properties were designated as "foreign key" columns, although their parent-child relationships were never defined in the database.
Recently, a co-worker went through and formally defined the relationships between the FKs and their parent tables in SQL Server. I am now attempting to update the entity model (update from database), and the new associations did not appear. I have resorted to removing the tables from the model and re-adding them. They now show the proper associations.
However, the mapping to Complex Type is gone. When I try to add it back, the updated mappings destroy the associations on those properties (I get a model error when saving). I am aware that Complex Types do not support associations.
Is it recommended to first remove the associations for the columns prior to re-mapping them to the complex type? Will EF observe the underlying key relationship even though the columns are not visible on the entity?

While I would still like to get some feedback on my questions, here's what I did to solve my issues.
1) Removed the associations generated by EF when deleting and re-adding tables from the database. Note that these relationships are only for the foreign key fields which were to be replaced by the complex type.
2) Followed the MS steps (found here) to refactor the requisite key properties to a complex type
3) Optional: It was necessary for me to edit the EDMX directly as XML in order to remove some lingering associations that could not be repaired with the designer
So far, my model functions as intended. I believe the FK relationships are observed during CRUD operations.

Entity framework move/archive data from one database to another

I have the following scenario:
I have a production database which is highly transactional. In order to keep queries efficient I would like to archive data from some of the tables to another database with exactly the same schema.
The relationships between tables are not very complex but any dependent objects would have to go with the archived data in order to uphold foreign key constraints.
Is there a simple way to do this using Entity Framework? I have tried to create two different contexts and add to one and delete from the other, but this is a bit of a tedious route.
If Entity Framework is not the best tool for this what is?

There is no simple way in EF5 to do this.
If your database is MSSQL you can make use of partitioning for archive tables (see http://blogs.msdn.com/b/felixmar/archive/2011/02/14/partitioning-amp-archiving-tables-in-sql-server-part-1-the-basics.aspx for more information).