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.
Related
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)
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 modeled a database with primary keys, foreign keys and unique indexes by using MySQL Workbench. I synchronized my model file with MySQL database and then created a console project in Visual Studio 2012. After that, i added a data entity model with an existing database. There is no problem. To understand if does entity framework create database successfully, i deleted the database. Then i ran the console program, database created successfully but unique indexes couldn't be exported to db. How can i solve this problem?
EF doesn't support unique keys. Unique keys are not used in the model and because of that it also doesn't create them when creating database from model. The only exception is manual creation of unique keys either through custom database intializer or migration (both are used in code-first approach).
I'm using VS2012 and creating a sample Entity Framework project that reads and writes to some tables that are used for import purposes. and do not have PK's or FK's in them - just null/notnull on the columns.
Can/should EF be made to insert records on these tables without that cryptic error:
Unable to update the EntitySet because it has a DefiningQuery
and no element exists in the
element to support the current
operation.
Or should I be looking elsewhere for database I/O?
Thanks!
Corey.
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.