I am using Entity framework version 5. In SQL Server database, I add a non-clustered index added for a column on a table. Do I need to run EF UI in Visual Studio to update the edmx file? If so, where I need to do that with EF UI? Thank you.
No, the nonclustered index is database-internal only - it doesn't have any impact on the entity data model (your .edmx file), so you don't need to update anything.
If SQL Server executes a query that will benefit from that new index, the query optimizer will use that index - and will return the data faster - but from the point of view of Entity Framework, nothing changes (no model properties need to be changed)
Related
I have a project that has a db first approach initially. However, I have difficulty managing to deployment it to the customers. Because it needs some db updates and I do this manually.
Is there any solution to turn over my DB first approach to the code first approach?
My project is developed in .net core and c# language and also my database firstly Oracle and also Postgre.
Thanks in advance.
You could probably:
create ordinary model classes out of the generated model classes
delete everything else related to the DbFirst approach
Create a code first migration based on the model classes mentioned above
Manually insert a row to the __efmigrationshistory table (in every database you use) with the name of you migration created above --> that way the first generated migration won't run again, as it shouldn't because your db schema is already created
Code First Entity Framework, from versions 5 - 6.1.1+, with migrations enabled stores database updates as "migration" classes. Each class has an accompanying resource file containing a serialized version of the model, i.e. the entities, properties, relationships, etc.
This serialized version of the model is then stored in the database in the __MigrationHistory table with a single row per migration. The information in this table is used to check what model version a database is at and thus what migrations still need to be run. It is also used during some database initialization strategies to determine if the running code's model matches the last migration deployed to that database.
In neither of the use cases for the __MigrationHistory table is the fully serialized model needed. At best only a hash of the model would appear to be required.
As we've had our code first database running for a while, the __MigrationHistory table is storing 36K per row for a total of 4MB. This isn't huge but seems unnecessary.
So the question: Why doesn't Entity Framework store a hash of the model in the __MigrationHistory table?
When you changing your model and adding a new migration, EF migrations generates Up and Down methods for you. And these changes comes from comparing full model from previous migration to your actual model.
I need to migrate data from many xmls to a sql server db and and it has to be done in a transactions.
I thought about EF and dbContext as it's a UOW in it's own right.
My question is
Can you do Database First at run time?
What I want to do is Read all tables from db store in class/dataset and map the db.column to equivalent in xml file and commit.
This has to work in such a way that if a table is added or column added it will work without any code changes as it is driven by db.
The problem I face is that with Db generated from model if a new column is required somebody later on "unfamiliar with EF" as to add the column "manual job".
I can do what I want with raw ado.net by reading db schema and mapping to a dataset but wondering if I could do it using EF.
Hope all clear
any suggestions
Yes you can.
You can use Entity Framework Power Tools which allows you to create Code-First file from Database of yours as you start like Code-First.
Or, you can use Database-first approach also. It's not that hard.
If you try to use database-first approach, please read my trial-and-error experience: post1, post2
Is there a way to tell EF not to update SSDL for the single table when doing Update Model From Database?
A little more details:
We're using EF 4.3 with Db-first approach (so, edmx and Update Model From Database).
We have a table that for some reasons does not have a primary key set in SQL Server, but have an auto-incremented Identity column that we can tell EF to use as primary key.
Since EF isn't finding any primary key in a table itself, it generates a DefiningQuery in SSDL for that table (and prevent update/inserts).
I can easily delete that DefiningQuery (and modify other EntitySet attributes) and everything works fine.
Except when I do another Update Model From Database that DefiningQuery is back again.
Is there a way to tell EF not to update SSDL for that single table?
Is there a way to tell EF not to update SSDL for the single table when
doing Update Model From Database?
Not with default designer provided in Visual Studio. Once you modify SSDL part of your EDMX file you should maintain it manually or write a script which will fix it every time you run Update from database.
Alternatively you can buy more powerful designer or extension to Visual Studio which will offer you selective update.
Anyway what you are trying to do should be avoided. If the database is owned by ERP you should do the access only through ERP programming API (real ERP has some). Otherwise you can break functionality of your ERP, corrupt ERP data, cause performance issues or even cause deadlocks.
We are testing EF 4.1 against DB2 tables on a Main Frame.
We are now able to generate EF models from DB2 tables and retrieve data :)
When we generate the EF model some relationships are included in the model and some are missing. It appears that the ones that are missing are composite keys.
Is this a limitation in EF that it is not able to handle composite keys?
Is it possible add the relationship manually to the model?
We fixed this by manually editing the edmx files.