SQL Server 2008存储过程的返回值

Question

Here is my stored procedure

ALTER PROCEDURE Delete
     @ID nvarchar(64),
     @value int = 0 output
AS
BEGIN
    IF(EXISTS(SELECT * FROM A where Ap = @ID))
    BEGIN
        set @value = 1
    END
    ELSE IF(EXISTS(SELECT * FROM B where Bp = @ID))
    BEGIN
        set @value = 2
    END
    ELSE
    BEGIN
        select * 
        from Table_D
    END
END

RETURN @value

Problem is that when I execute it, this does not return any value

Answer 1

There are multiple ways of returning status information from a stored procedure to an application. Each has its pros and cons; no single technique can definitely be said to be the right one in all circumstances. Even so, I'll start off with:

TL;DR: recommendation

Use RAISERROR if your stored procedure runs into trouble and cannot return the data it normally returns. Use OUTPUT parameters for information the client isn't free to ignore, but which isn't logically part of your result. Use the return value if you have an informational status code that the client is free to ignore. Use additional result sets only if you know what you're doing.

RAISERROR

If your stored procedure encounters an error and can't return any data, you can use RAISERROR to terminate execution and cause an exception to be raised on the client side.

CREATE PROCEDURE [Delete]
     @ID nvarchar(64)
AS BEGIN
    IF(EXISTS(SELECT * FROM A where Ap = @ID))
    BEGIN
        RAISERROR('Wrong. Try again.', 11, 1);
        RETURN;
    END
    ELSE IF(EXISTS(SELECT * FROM B where Bp = @ID))
    BEGIN
        RAISERROR('Wrong in a different way. Try again.', 11, 2);
        RETURN;
    END
    ELSE
    BEGIN
        select * 
        from Table_D
    END
END

The second parameter (severity) must be set to at least 11 to make the error propagate as an exception, otherwise it's just an informational message. Those can be captured too, but that's out of the scope of this answer. The third parameter (state) can be whatever you like and could be used to pass the code of the error, if you need to localize it, for example. User-generated message always have SQL error code 50000, so that can't be used to distinguish different errors, and parsing the message is brittle.

The C# code to process the result:

try {
    using (var reader = command.ExecuteReader()) {
        while (reader.Read()) {
            ...
        }
    }
} catch (SqlException e) {
    Console.WriteLine(
        "Database error executing [Delete] (code {0}): {1}", e.State, e.Message
    );
}

This is a natural fit for errors because the code to actually process the data stays what it is, and you can handle the exception at the right location (rather than propagating a status code everywhere). But this method is not appropriate if the stored procedure is expected to return a status that is informational and not an error, as you would be catching exceptions all the time even though nothing's wrong.

Output parameter

A stored procedure can set parameter values as well as receive them, by declaring them OUTPUT :

CREATE PROCEDURE [Delete]
     @ID nvarchar(64),
     @StatusCode INT OUTPUT
AS BEGIN
    IF(EXISTS(SELECT * FROM A where Ap = @ID))
    BEGIN
        SET @StatusCode = 1;
    END
    ELSE IF(EXISTS(SELECT * FROM B where Bp = @ID))
    BEGIN
        SET @StatusCode = 2;
    END
    ELSE
    BEGIN
        SET @StatusCode = 0;
        select * 
        from Table_D
    END
END

From C#, this is captured in a parameter marked as an output parameter:

SqlParameter statusCodeParameter = command.Parameters.Add(
    new SqlParameter {
        ParameterName = "@StatusCode",
        SqlDbType = SqlDbType.Int,
        Direction = ParameterDirection.Output 
    }
);
using (var reader = command.ExecuteReader()) {
    int statusCode = (int) statusCodeParameter.Value;
    if (statusCode != 0) {
        // show alert
        return;
    }
    while (reader.Read()) {
        ...    
    }
}

The benefits here are that the client cannot forget to declare the parameter (it must be supplied), you're not restricted to a single INT , and you can use the value of the parameter to decide what you want to do with the resul set. Returning structured data is cumbersome this way (lots of OUTPUT parameters), but you could capture this in a single XML parameter.

Return value

Every stored procedure has a return value, which is a single INT . If you don't explicitly set it using RETURN , it stays at 0.

CREATE PROCEDURE [Delete]
     @ID nvarchar(64)
AS BEGIN
    IF(EXISTS(SELECT * FROM A where Ap = @ID))
    BEGIN
        RETURN 1
    END
    ELSE IF(EXISTS(SELECT * FROM B where Bp = @ID))
    BEGIN
        RETURN 2
    END
    ELSE
    BEGIN
        select * 
        from Table_D
    END
END

From C#, the return value has to be captured in a single special parameter marked as the return value:

SqlParameter returnValueParameter = command.Parameters.Add(
    new SqlParameter { Direction = ParameterDirection.ReturnValue }
);
using (var reader = command.ExecuteReader()) {
    // this could be empty
    while (reader.Read()) {
        ...
    }
}
int returnValue = (int) returnValueParameter.Value;

It's important to note that the return value will not be available until you've processed all other result sets that the stored procedure generates (if any), so if you're using it for a status code that indicates there are no rows, you must still process the empty result set first before you have the status code. You cannot return anything other than an INT . Frameworks/OR mappers often have no support for the return value. Finally, note that the client is not required to do anything with the return value, so you have to carefully document its intended use.

Result set

The stored procedure can simply return what it wants as the result set, just like it's returning the other data. A stored procedure is allowed to return multiple result sets, so even if your status is logically separate from the other data, you can return it as a row.

CREATE PROCEDURE [Delete]
     @ID nvarchar(64)
AS BEGIN
    DECLARE @StatusCode INT = 0;
    IF(EXISTS(SELECT * FROM A where Ap = @ID))
    BEGIN
        SET @StatusCode = 1;
    END
    ELSE IF(EXISTS(SELECT * FROM B where Bp = @ID))
    BEGIN
        SET @StatusCode = 2;
    END

    SELECT @StatusCode AS StatusCode;

    IF @StatusCode = 0
    BEGIN
        select * 
        from Table_D
    END
END

To process this with C#, we need SqlDataReader.NextResult :

using (var reader = command.ExecuteReader()) {
    if (!reader.Read()) throw new MyException("Expected result from stored procedure.");
    statusCode = reader.GetInt32(reader.GetOrdinal("StatusCode"));
    if (statusCode != 0) {
        // show alert
        return;
    }
    reader.NextResult();
    while (reader.Read()) {
        // use the actual result set
    }
}

The main drawback here is that it's not intuitive for a stored procedure to return a variable number of result sets, and very few data frameworks/OR mappers support it, so you'll nearly always end up writing manual code like this. Returning multiple result sets is not really a good fit for returning a single piece of data like a status code, but it might be an alternative to returning structured data in an XML output parameter (especially if there's lots).

Answer 2

The return seems to be out of scope of the procedure. Try:

ALTER PROCEDURE Delete
    @ID nvarchar(64),
    @value int=0 output
AS
BEGIN

    IF(EXISTS(SELECT * FROM A where Ap=@ID))
    BEGIN
        set @value=1
    END

    ELSE IF(EXISTS(SELECT * FROM B where Bp=@ID))
    BEGIN
        set @value=2
    END

    ELSE
    BEGIN
    set @value=5
    end --end if

    RETURN @value
end --end procedure

This is where using tabbing properly makes the code a lot more readable, and these problems more obvious

Answer 3

Don't use the output parameter. Rather, use this:

ALTER PROCEDURE Delete
@ID nvarchar(64)

AS
BEGIN

DECLARE @value int
SET @value = 0

IF(EXISTS(SELECT 1 FROM A where Ap=@ID))
BEGIN
set @value=1
END

ELSE IF(EXISTS(SELECT 1 FROM B where Bp=@ID))
BEGIN
set @value=2
END

ELSE
BEGIN
set @value=5
end

Select @value as Value, * from Table_D
end

Answer 4

Can you try running the SP as the script below?

declare @pID as nvarchar(64)
declare @pValue as int

set @pID = 1 -- Your ID filter

exec Delete @pID, @pValue OUTPUT

select @pValue