Возврат логического значения из хранимой процедуры T-SQL

Question

Каков наиболее эффективный способ возврата логического (истинного/ложного) из хранимой процедуры T-SQL? Я хочу, чтобы он выполнял запрос и возвращал, удалось ли это или нет. Я звоню через ASP.

Позвольте мне уточнить, что я делаю.

Если запись существует в таблице (с указанием того, что документ уже зарезервирован и не может быть извлечен), я хочу уведомить пользователя на лицевой стороне. Я определю это, проверив Exists ... в T-SQL и затем каким-то образом вернув это обратно в Classic ASP (возвращаемое значение, параметр, поле набора записей).

Получает ли это какой-либо ответ более разумным?

Answer 1

У меня есть эта функция в ASP, которая предполагает, что SP принимает последний параметр как целочисленное выходное значение.

Возвращение и целое число лучше, потому что вы можете вернуть несколько состояний, а не только true/false.

Function RunSPReturnInteger(strSP , params()) 
    On Error resume next 

    ''// Create the ADO objects 
    Dim cmd 
    Set cmd = server.createobject("ADODB.Command") 

    ''// Init the ADO objects & the stored proc parameters 
    cmd.ActiveConnection = GetConnectionString() 
    cmd.CommandText = strSP 
    cmd.CommandType = adCmdStoredProc 

    ''// propietary function that put the params in the cmd 
    collectParams cmd, params 

    ''// Assume the last parameter is outgoing 
    cmd.Parameters.Append cmd.CreateParameter("@retval", adInteger, adParamOutput, 4) 

    ''// Execute without a resulting recordset and pull out the "return value" parameter 
    cmd.Execute , , adExecuteNoRecords 
    If err.number > 0 then 
     BuildErrorMessage() 
     exit function 
    end if 
    RunSPReturnInteger = cmd.Parameters("@retval").Value 

    ''// Disconnect the recordset, and clean up 
    Set cmd.ActiveConnection = Nothing 
    Set cmd = Nothing 

    Exit Function 
End Function 

Answer 2

Возврат bit: «целочисленный тип данных, который может принимать значение 1, 0 или NULL».

Answer 3

Неплохая идея.

Возвращаемое значение, выходной параметр или набор записей будут неопределенными или не заданными или частичными, если у вас есть ошибка. Например, ошибка CAST прерывает код (без TRY/CATCH).

Гораздо лучший метод будет опираться на обработку исключений, например:

BEGIN TRY 
    ... 
    --assume worked 
END TRY 
BEGIN CATCH 
    DECLARE @foo varchar(2000) 
    SET @foo = ERROR_MESSAGE() 
    RAISERROR (@foo, 16,1) 
END CATCH 

Однако, я подозреваю, что я мог бы ответить на ваш вопрос позже о «почему не SQL Server делать ...?». ..