Entity Data Models have a lot of rules. They are necessary for the integrity of the model, though if you are not familiar with depth of EDMs and *why* these rules exist, many of the mapping rules may seem to make no sense when it comes trying to implement them. This gets hairy when you are mapping stored procedures. Roger Jenning’s solution is to create stored procedures that will map properly, rather than suffer wtih the ones that already exist.

The first level of using Stored Procedures is that they work very easily for existing entities that are simple, have no EntityReferences (these involve Foreign Keys) , don’t involve inheritance and map directly to a single table in your database.

The next is stored procs that map nicely to entities which don’t involve inheritance but if your entities have any relationships, you will probably run into a wall with a delete procedure. Here’s why.

Stored Procs become Functions in the Entity Data Model. If you want to use these functions rather than the dynamic SQL that Entity Framework will create, it’s an all or nothing scenario. You need to map an Insert, and Update and a Delete. (Read procs doesn’t come into play here). There are plenty of blog posts and other resources on how to do this including this tutorial I wrote for the DataDeveloper.net site.

If you have a relationship in your entity, you can map that easily enough to a foreign key parameter in the function mappings and this makes sense with Inserts and Updates. With deletes, generally you only have a primary key (eg ContactID) as the parameter for the stored procedure. But here is where the EDM rules come in to play. A foreign key value that is used in a stored proc, would in most cases map to the EntityKey of a navigation property.

In other words, if you have a stored proc to insert SalesOrders, that procedure will have a parameter for CustomerID. The Order Entity this is mapping to has a relationship to the Customer entity and contains a Customer navigation property. The mapping therefore would link the CustomerID paraemter to Order.Customer.CustomerID.

By doing this, you are involving the association that exists between the Customer entity and the Order entity.

The EDM rule is that if you are involving an association in ONE of the function mappings, you have to use it in ALL o the function mappings.

Therefore a stored proc to delete an order, which only has an OrderID parameter will need also to have a CustomerID parameter because you are required to map SOMETHING to the Customer entity.

This then breaks a possible rule. It means you need to go to the dba and beg them to add this parameter into the stored procedure even though it doesn’t get used.

The alternative is to just go in and modify the SSDL to trick it into thinking that that parameter exists which will make the model happy and the database won’t care at all. IT doesn’t ever really get used.

So if the actual stored proc is

PROCEDURE DeleteOrder

@OrderID int

AS

DELETE from ORDERS WHERE OrderID=@OrderID

and the original function in SSDL is

 <Function Name=”DeleteOrder” Aggregate=”false” BuiltIn=”false” NiladicFunction=”false”
            IsComposable=”false” ParameterTypeSemantics=”AllowImplicitConversion” Schema=”dbo”>
     <Parameter Name=”OrderID” Type=”int” Mode=”In” />
 </Function>

You just need to add a new parameter to the SSDL

 <Function Name=”DeleteOrder” Aggregate=”false” BuiltIn=”false” NiladicFunction=”false”
            IsComposable=”false” ParameterTypeSemantics=”AllowImplicitConversion” Schema=”dbo”>
     <Parameter Name=”OrderID” Type=”int” Mode=”In” />
     <Parameter Name=”CustomerID” Type=”int” Mode=”In” />
 </Function>

This is all fine and good until you need to update the model, because the SSDL will lose all customizations.

I keep my customizations listed in a separate text file so that if I must update the model,  I can replace them.

It’s not pretty, but when I don’t have a lot of customizations, I will choose this over bugging the dba. Okay, in my world, I’m the DBA (how pathetic is that) but I’m trying to think about enterprise developers and real DBAs.

I started out wanting to write about dealing with stored procs for entities that are inherited, but I guess that will have to come later!