Rendimiento TSQL con @@ Error y ¿Pueden ser reemplazados?

he heredado código que se parece a esto:Rendimiento TSQL con @@ Error y ¿Pueden ser reemplazados?

procedimiento almacenado UpdateSomeStuff

Update Table1 Set [email protected] 

IF @@Error > 0 Goto ERR 

Update Table2 Set [email protected] 

IF @@Error > 0 Goto ERR 

RETURN 0 

ERR: 

return -1;

este SP es llamado por ADO.NET en C# como éste

try 
{ 
    myCommand.ExecuteNonQuery(); 
} 
catch (System.Exception ex) 
{ 
    _log.Error(ex); 
    throw(); 
} 
finally 
{ 
    if(myConnection!=null) 
    { 
      myConnection.Close(); 
    } 
}

yo sólo pido yo mismo: ¿Es la parte IF @@ Error> 0 Goto ERR bueno para algo? Si ocurre un error, la sp regresará de todos modos y se detectará una excepción en el método de llamada.

El código de llamada no maneja el valor de retorno 0 y -1. Mi plan sería eliminar todo el manejo de errores en el procedimiento almacenado y tener el mismo resultado. ¿Estoy en lo cierto o hay algo que eché de menos?

Fuente

2011-10-27 Mathias F

No, si hay un error, las sentencias restantes del SP seguirán ejecutándose. Si la intención es NO continuar la ejecución del T-SQL restante, debe mantener las comprobaciones de errores en su lugar. Pero me sorprende que no haya transacciones involucradas en el SP original. – HardCode

Mi '2 centavos' que va a matar el rendimiento mediante la eliminación si el error @ declaraciones. así que o bien implementas try catch como dice mitch o no los eliminas. Solo piense si hay un error en el primer enunciado, entonces no intentará ejecutar el 2º enunciado, y así sucesivamente, si tiene @ declaraciones de error.

y si los elimina, el servidor sql va a probar la siguiente declaración hasta que llegue al límite cuando decida que no puede continuar con el procesamiento posterior.

Fuente

2011-10-27 10:24:14

Un mejor enfoque (SQL Server 2005 en adelante) es utilizar TRY..CATCH:

BEGIN TRY 
    -- Perform operations here 
END TRY 
BEGIN CATCH 
    SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_MESSAGE() AS ErrorMessage; 
END CATCH

Una buena referencia es: Error Handling in SQL 2005 and Later

Fuente

2011-10-27 09:38:48

¿Esto todavía se ejecutará en el bloque catch del método de llamada? Porque eso es lo que necesito. –

Si genera un error si su procedimiento almacenado, puede ser atrapado por el bloque catch del código C#. –

Rendimiento TSQL con @@ Error y ¿Pueden ser reemplazados?

Respuesta

Cuestiones relacionadas