I want to use Entity Framework to a load a number of sql tables into memory from my c# app before performing some work on them and sending changes back to the database. I only want to hit the database once when I load the data and once more when I update changes. Should I load the tables into a dataset or is there a better way to achieve this?
In such case you can't use entity framework. Entity framework will hit database for once for loading each table (unless there are relations which can load all tables in single query as #Jakub suggested) and it will hit database for each performed change. EF doesn't have command batching and each modified, inserted or deleted entity will cause separate roundtrip to DB.
Turn off lazy loading or use Include() to specify related entities that should be loading in a single query.
If you're using CTP5 look here: http://blogs.msdn.com/b/adonet/archive/2011/01/31/using-dbcontext-in-ef-feature-ctp5-part-6-loading-related-entities.aspx
Related
I have a repository pattern in my application, to implement the repository i use Linq to SQL, but apart from the automatically generated entities, i create my own entity classes to maintain abstraction.
The problem is when i try to update entities.
Since i fetch from the repositories the custom entities that i created, and not the ones that Linq to SQL created, all changes that i do to the fetch entities are not recorded by the Linq to SQL mechanism.
So when i write:
dbContext.SubmitChanges()
Nothing happens.
What can i do to solve this?
Thanks,
Arik
I have done a couple of projects with the same pattern that you are using. What I did was, before calling the dbContext.SaveChanges(), load in the corresponding generated entity or entities from the database and then copy over all the fields from the custom entities that were edited to those loaded entities.
I have an odd situation. I am working on a project with a very large existing database that is completely unrelated, but does contain corresponding table id's. It's as if someone copied the database but never related the tables.
In Entity Framework, is there a way to go EF code first and create the relationships in code, but Not apply those relationships in the database? I would like to go through and relate the database but the client doesn't want to pay to fix it.
Thanks!
In this instance, it seems you would be best to add relationships directly to your database (or to a duplicated database for testing/staging) and then just update your entities using your test connection and regression test your app.
I have a very basic question about database programming, here's the problem:
I want to create/read/edit/etc.. data from database without using Entity Framework, and for this job I've chosen SqlFu.
I want to put the stored procedures to create, update, delete on the database and the views to get entities.
My doubt is: If I have an table Employee, that has a one-to-many relationship to Tasks table, when I create a Sql View to retrieve Employee entity, should I retrieve the data in Tasks table that is related to the employee?
If so, how to do that with a single View in SQL Server? If not, I should have different Sql Views that retrieve data from each table and bind the relationship in the application?
I'm a bit lost in this subject :S
No, you don't need. You can retrieve any data from any table/view without need to always retrieve data from any related table's.
On ORM layer it's should be implemented as lazy loading - like in EF. But not in MicroORM's like SQLFu - there you should manually do something like
employeeObject.Tasks = db.Query<Task>("select * from tasks where employeid=#0", employeeObject.Id)
When and if you actually need it.
Yes, you should retrieve data from each table and bind the relationship inside application code.
I'm about to start a new project and I'd like to use Entity Framework Code First migrations; i.e., write the database in code and have it all auto-generated for me and the schema updated etc.
However, my stumbling block is that I have one lookup table which I need to import and has over 2 million records (it's a post code lookup table).
My question is, how do you deal with such large pre-populated lookup tables within Entity Framework Code First migrations?
Your migration doesn't actually have to drop/recreate the whole table (and won't unless you specify that it should). Normally, the migrations just do the Up/Down methods to alter the table with additional columns, etc.
Do you actually need to drop the table? If so, do you really need to seed it from EF? The EF cost for doing 2 million inserts will be astounding, so if you could do it as a manual step with something more efficient (that will use bulk inserts), it would be very much preferred.
If I had to do that many inserts, I would probably break it out into SQL files and do something like what's mentioned here: EF 5 Code First Migration Bulk SQL Data Seeding
How can I run a prepared statement against a database and have the returned rows automatically attach to the entity framework data context? Essentially, how can I achieve the same functionality of ObjectContext.Execute except using a prepared SQL command.
Use ObjectContext.Translate.