I'm working on a project that works with datasets, but now will be with Entity Framework(any version).
My idea is to do the following
Reuse stored procedures (only selects with parameters - one or more tables)
To insert, delete and update will use Entity Framework
What is the best way (fast, not complex) to create INSERT UPDATE DELETE for those stored procedures?
I tried with context.SaveChanges but apparently does not work with imported SQL Server stored procedures. Any ideas for this project?
Related
I am new to Informix stuff and I have a legacy database (IBM Informix) and there are thousands of stored procedures written. Now I am trying to create the model class using Entity framework database first approach.
The problem I am facing now is;
When I am trying to add stored procedures from Update Model from Database, noting is list down in the Stored Procedures and Functions. Further I have checked with the server and found that all stored procedures are stored in sysprocedures table.
My questions are;
How can I import these procedures into Entity framework?
Is it possible to invoke stored procedure without importing?
I'm working on a green-field application that has a corporate mandate that Stored Procedures are used for all database interaction.
I'd like to use Entity Framework and leverage Stored Procedure Mapping to gain the benefits of the ORM.
Since we will be developing the database and .NET application in parallel, I'm looking for information to help the database developer/administrator. Does anyone know of a consolidated guide on how to design tables and stored procedures so they can be best integrated with the Entity Framework?
A couple tips I've collected are:
Update Stored Procedures require exactly 1 parameter per table column
There must be an insert, update, and delete Stored Procedure for every table
I want to know as much about how the database should be designed for easy use with Entity Framework because the database is very difficult to change later in our environment.
I wrote a blog post describing the limitations of using mapping in this way after working on this for several months:
The Pitfalls of Mapping the Entity Framework to Stored Procedures
If you want to use Stored Procedures are used for all database interaction, I just don't see the need to use Entity Framework. One good reason of EF is to save time to write T-SQL, and if you don't take advantage of this, why even use EF?
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.
At my client site the database user has permissions to execute stored procedures only.
Database user doesn’t have permissions to execute queries directly.
But I have used Entity Framework, and no stored procedures used.
What can I do?
In such scenario it is better to use native SQL + ADO.NET directly. The main power of EF is in mapping, linq / ESQL querying and loading strategies. Once you are limited to stored procedures you will lose support for latter two = no querying and no loading strategies. You will still have support for mapping but it will come with performance costs and it will demand strict limitations on your stored procedures.
The Entity Framework allows you to map each entity to a set of stored procedures that will execute the insert, delete and update.
That way the user won't have to execute queries directly when modifying the data in your database.
If the user also doesn't have Select permissions, you need stored procedures to access the data. The Entity Framework can help you because you can import Stored Procedures in the SSDL part of your EDMX and then you can map those stored procedures to functions on your ObjectContext.
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.