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.
Related
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).
We currently have a system with quite large database and stored procedures are used both for CUD and querying. DataSets are used to retrieve the results from the SP querys.
Now we are looking into developing another project against the same database using Entity Framework. When querying the database, the stored procedures often perform a lot of joins to gather some fields not in the target table, but data from the joined tables that is needed by the client in some way. When using DataSets, all the fields returned by the SP was included in the DataTable. So the DataTable doesn't actually match the target database table.
What is the correct way of handling this scenario in EF? When creating my model, the entities are mapped to each table which as mentioned above only sometimes matches the result of the SP. Can I add the "additional" fields of the SP query result to the entity class as properties and have them filled by the query but with these properties being excluded when it comes to CUD on the specific entity type? Seems like the EF-way, if queried through LINQ to Entities and not SPs, would be to have entity instances with relational properties to the joined entities so that using those "additional" properties would be done by navigating the relational properties?
You can define an arbitrary complex type (just a class that's generated for you, to match the columns and datatypes returned by the stored procedure) as the return type for your stored procedure in Entity Framework (as of version 4 and newer) - no problem here.
See Stored Procedures in the Entity Framework for a great explanation of all things related to using stored procedures in Entity Framework.
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.