Table-Valued Parameter in Stored Procedure and the Entity Framework 4.0

I have a stored procedure in SQL Server 2008 called 'GetPrices' with a Table-Valued Parameter called 'StoreIDs'.

This is the type i created for this TVP:

CREATE TYPE integer_list_tbltype AS TABLE (n int)

I would like to call the SP from my Entity Framework. But when I try to add the Stored Procedure to the EDM, i get the following error:

The function 'GetPrices' has a parame开发者_如何学编程ter 'StoreIDs' at parameter index 2 that has a data type 'table type' which is not supported. The function was excluded.

Is there any workaround this? Any thoughts?

Fabio

I agree that passing in a CSV sting is the best solution in this case. I would like to propose simpler way to split csv string, without creating tables and functions, by using CTE:

declare @separator char(1);
set @separator = ',';

;with baseCte as
(select left(@ValueList, charindex(@separator, @ValueList) - 1) as Value,
substring(@ValueList, charindex(@separator, @ValueList) + 1, len(@ValueList)) 
as rest
union all
select left(rest, charindex(@separator, rest) - 1) as Value, 
substring(rest, charindex(@separator, rest) + 1, len(rest)) from baseCte
where len(rest) > 1
)
select Value from baseCte
OPTION (MAXRECURSION 0);

Since you can't use a table parameter, try passing in a CSV sting and have the stored procedure split it into rows for you.

There are many ways to split string in SQL Server. This article covers the PROs and CONs of just about every method:

"Arrays and Lists in SQL Server 2005 and Beyond, When Table Value Parameters Do Not Cut it" by Erland Sommarskog

You need to create a split function. This is how a split function can be used:

SELECT
    *
    FROM YourTable                               y
    INNER JOIN dbo.yourSplitFunction(@Parameter) s ON y.ID=s.Value

I prefer the number table approach to split a string in TSQL but there are numerous ways to split strings in SQL Server, see the previous link, which explains the PROs and CONs of each.

For the Numbers Table method to work, you need to do this one time table setup, which will create a table Numbers that contains rows from 1 to 10,000:

SELECT TOP 10000 IDENTITY(int,1,1) AS Number
    INTO Numbers
    FROM sys.objects s1
    CROSS JOIN sys.objects s2
ALTER TABLE Numbers ADD CONSTRAINT PK_Numbers PRIMARY KEY CLUSTERED (Number)

Once the Numbers table is set up, create this split function:

CREATE FUNCTION [dbo].[FN_ListToTable]
(
     @SplitOn  char(1)      --REQUIRED, the character to split the @List string on
    ,@List     varchar(8000)--REQUIRED, the list to split apart
)
RETURNS TABLE
AS
RETURN 
(   ----------------
    --SINGLE QUERY-- --this will not return empty rows
    ----------------
    SELECT
        ListValue
        FROM (SELECT
                  LTRIM(RTRIM(SUBSTRING(List2, number+1, CHARINDEX(@SplitOn, List2, number+1)-number - 1))) AS ListValue
                  FROM (
                           SELECT @SplitOn + @List + @SplitOn AS List2
                       ) AS dt
                      INNER JOIN Numbers n ON n.Number < LEN(dt.List2)
                  WHERE SUBSTRING(List2, number, 1) = @SplitOn
             ) dt2
        WHERE ListValue IS NOT NULL AND ListValue!=''
);
GO 

You can now easily split a CSV string into a table and join on it or use it however you need:

CREATE PROCEDURE YourProcedure
(
    @CSV_Param   varchar(1000)
)
AS

--just an example of what you can do
UPDATE t
    SET Col1=...
    FROM dbo.FN_ListToTable(',',@CSV_Param) dt
        INNER JOIN TBL_USERS                 t ON  CAST(dt.value AS INT)=t.id

GO

You can use the ObjectContext.Connection property to use ADO.NET to create and use your table-valued parameters. This might not be acceptable, but if you want to use this awesome SQL Server 2008 feature and the EF, this seems to be you're only choise.

You can then choose to extent the partially generated object context with the method to take care of all the low level ADO.NET stuff. Like this:

public partial class FriendsOnBoardEntities : ObjectContext
{
    public IList<int> GetPrices(int n)
    {
        // 'low-level' ado.net stuff here.
        // Use SqlParameters, SqlCommand and what not...
    }
}

You might want to vote on this at microsoft connect

Update: MS does not use Connect for features any more. They only use it for bug reports. To vote for an EF feature you need to go the EF User Voice site.

To vote for this specific issue on User Voice go here.