is there a way, how to save EF (STE) entities in to temporary tables?
I'm trying to achieve this:
1) save my STE to temporary tables
2) run some stored procedures on them
3) depending on result from procedures, do something else..
Thank you.
EF will not handle this. EF saves the entity to table(s) defined in mapping but the mapping is defined at design time. You cannot decide to save the entity to other table at runtime through EF without changing its mapping and that would be highly inefficient - changing mapping at runtime is not a supported use case so it is quite complicated and moreover applying a new mapping is the most expensive operation in EF.
You need just another stored procedure to insert your data to temporary table. Depending on the logic you expect you can either map that procedure to insert operation for the entity (but in such case your procedure will be used every time you insert a new entity) or simply execute it directly.
Related
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.
I am looking into adding history tables to my database. The easiest way is to intercept all Insert, Update and Delete calls that EF Makes and add in a merge that will also insert a history row into a history table.
Right now all my Entities just let EF figure out how to do the inserts, updates and deletes.
If I go and add in stored procedures (instead of the EF Generated stuff) will EF still function the same on the business tier?
Or does it change how I have to work with my entities? If so, how?
Everything works the same, it is transparent.
Stored procedures need to return the rows affected, in order for EF to know that the update succeeded or not. Additionally, if you do an update and need to map any property back to your entity (e.g. timestamps) you must select them in the sproc and then map them back in the EF designer (since you can only have one output parameter, and that should be the rows affected).
You might consider using triggers on the DB to solve your issue, though?
Doing this in stored procedures means that you will write all inserts, updates and deletes yourselves. It is like throwing 30% of feature set (and 50% productivity) away. Create audit records in your application and save them together with main records through EF.
I have some tables which should add to my database every year and name of databases contains the year (like sell2005) and iv'e written some ef queries on these tables ,and queries can only be on a single entity (like sell2005) but what should i do when sell2006 or sell2007 add ? how can i manage them with that single query which iv'e written before?
thank you.
There is no easy way. EF is simply not tool for this scenario. For EF you must have "single table" so you must either use partitioning with one real database table partitioned by year or you must build a view on top of these tables.
The problem is that in EF you have strict relation between classes and tables. You cannot have single class mapped to multiple tables even if they are exactly same (except inheritance which is not solution for you). So the workaround would require to have multiple SSDL/MSL mappings - one for each table and construct correct context instance with correct mapping for every query. As I know dynamic changes of mapping are not possible (except modifying SSDL/MSL files before using them).
I am using a stored procedure with an EF 4 model.
To accomplish this I'm going through the following steps:
I add the stored procedure to my Model Store by Updating from the database and selecting it.
Added a function import to point to the stored procedure
The stored procedure returns the result of a query joining multiple tables etc so in the "Returns Collection Of" area I specify a Complex Type and use the Get Column Information button below to generate the complex type returned.
Here is where my issue arises: when I use the "Generate Database From Model" option, it removes the stored procedure mapping from the Model Store.
My question is:
How can I use the "Generate Database From Model" option but ignore the Stored Procedures mapping?
In the model properties there is a "Database Generation Workflow" that is TablePerTypeStrategy but apparently this has the added effect of removing stored procedures from the model store.
I am using model first but also mapping stored procedures to function imports. Unfortunately when I make updates to the model and try to generate the database from the model, it removes my stored procedures and unmaps my function imports.
To get around this, I do an undo after I generate the database from the model on the EDMX (and keep the updated sql script). This updates the database just fine for me and restores my stored procedures and function imports as well.
These two approaches should not be used together! Use either database first (Update model from database) or model first (Generate database from model). I'm even surprised that it didn't delete your stored procedures in the database as well.
When you select Generate database from model it deletes whole storage description and mapping from your EDMX and generates a new one.
We have an application that creates new tables at runtime, but always with the same table schema. The only thing that varies from one of these tables to the next is the table name. Is it possible to access these tables using Entity Framework, specifying which table to access by name?
Entity Framework is not designed for DDL, it's an ORM tool for data access. You would want to use a simple ADO.NET query to create/drop the table.
Creating and dropping tables for every user session will make your log file grow very big very fast. I would consider carefully the reasons you think this is necessary. If the data is temporary, why not save the Session ID in each row and truncate the table on a daily basis?
UPDATE:
No, not really. The Entity Data Model is not dynamic, it's a static XML document that describes the structure of the database. If you want to interact with a table with a dynamic name, you're going to have to stick to "classic" ADO.NET.
With Linq to SQL I guess it would be possible with a stored procedure taking the table Name as a parameter.
A nice post about SP in L2SQL: http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx
I don't know if that feature exists in EF.