Entity Framework - stored procedure return value
I am trying to get the return value of a stored procedure. Here is an example of such a stored procedure:
select
Name,
IsEnabled
from
dbo.something
where
ID = @ID
if @@rowcount = 0
return 1
return
This is a simple select. If 0 rows are found, my result set will be null, but I will still have a return value.
This is a bad example, as this is a select, so sure I could find if 0 rows were returned. However, on an Insert, delete, or other calls, we need this return value to know if there was a problem. I have been unable to find a way to get this return value. I can get output values, I can get result sets, but no return value.
I can get the return value if I call SQL manually, or even if I run a SqlCommand
using the Entity Framework, but this is not what I want to do.
Has anyone ever been able to get the return value from a stored procedure using Entity Framework?
Thanks for the help!
Solution 1:
I guess support of stored procedure return values depends on version of Entity framework. Although directly returning value didn't work for me I managed to get value using OUTPUT stored procedure parameter. Example:
USE [YOUR_DB_NAME]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[TestReturnValue]
@InputValue int = 0,
@Result int OUTPUT
AS
BEGIN
SET NOCOUNT ON;
SELECT @Result = @InputValue
RETURN(@InputValue);
END
This is test code:
void TestReturnValue()
{
using (var db = new YourDBContext())
{
var result = new System.Data.Objects.ObjectParameter("Result", 0);
Console.WriteLine("SP returned {0}", db.TestReturnValue(123, result));
Console.WriteLine("Output param {0}", result.Value);
}
}
And this is output:
SP returned -1
Output param 123
As you see directly returned value output some rubbish but OUTPUT parameters works!
This article provides general info on two ways of returning values from SP
Hope this helps
Solution 2:
No. Entity Framework doesn't have rich stored procedure support because its an ORM, not a SQL replacement.
As you have already discovered, if you need to use less common (more advanced?) features of stored procedures, you'll have to use good old fashioned ADO.NET.