Si creo un procedimiento almacenado en SQL y lo llamo (EXEC spStoredProcedure) dentro de BEGIN/END TRANSACTION, ¿este otro procedimiento almacenado también cae dentro de la transacción?Ejecutando un procedimiento almacenado dentro de BEGIN/END TRANSACTION
No sabía si funcionaba como try/catch en C#.
Sí, todo lo que haga entre la transacción Begin y Commit (o Rollback) es parte de la transacción.
Creo en MS SQL Server la ejecución del procedimiento almacenado ocurriría dentro de la transacción, pero tenga mucho cuidado con esto. Si tiene transacciones anidadas (es decir, transacción fuera del procedimiento almacenado y una transacción diferente dentro del procedimiento almacenado), una reversión afectará TODAS las transacciones, no solo la transacción circundante más cercana.
Sí, todas las llamadas a procedimientos almacenados anidados se incluyen en el alcance de la transacción. Si está utilizando SQL Server 2005 o posterior, puede usar Try ... Catch también. Here es más detallado sobre eso.
Suena genial, muchas gracias. Terminé haciendo algo como esto (porque estoy en 05)
BEGIN TRY
BEGIN TRANSACTION
DO SOMETHING
COMMIT
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0
ROLLBACK
-- Raise an error with the details of the exception
DECLARE @ErrMsg nvarchar(4000), @ErrSeverity int
SELECT @ErrMsg = ERROR_MESSAGE(),
@ErrSeverity = ERROR_SEVERITY()
RAISERROR(@ErrMsg, @ErrSeverity, 1)
END CATCH
Esto funciona! ¡Gracias! No es como la solución de KM en http://stackoverflow.com/questions/2715184/tsql-create-a-stored-proc-inside-a-transaction-statement que arroja un error relacionado con la red – knocte
como Chris mencionó, se debe tener cuidado con la transacción rodar hacia atrás.
Específicamente esto:
IF @@TRANCOUNT > 0 ROLLBACK
no es siempre lo que quiere. Se podría hacer algo como esto
IF(@@TRANCOUNT = 1) ROLLBACK TRAN
ELSE IF(@@TRANCOUNT > 1) COMMIT TRAN
RETURN @error
De esta manera, el proc llamada puede inspeccionar el valor devuelto por el procedimiento almacenado y determinar si se quiere comprometerse de todos modos o continuar a propagarse por el error.
La razón es que 'COMPRAR' simplemente disminuirá el contador de su transacción. Una vez que disminuye el contador de transacciones a cero, se producirá una confirmación real.
@Chris, no lo sabía.
Al buscar en Google para obtener más información, me encontré con this - puede establecer 'puntos de guardado', que se pueden revertir sin revertir toda la transacción.
Podría ser útil en esta situación.
Como se mencionó Chris y James, debe tener cuidado cuando se trata de transacciones anidadas. Hay un conjunto muy buenos artículos sobre el tema de las transacciones escritas por Don Peterson en SQL Server Centra l, recomiendo tener una lectura de los:
Aquí hay:
Esto no es del todo cierto.En realidad, las operaciones en variables de tabla están fuera del alcance de la transacción; una reversión no afecta los cambios que se hayan realizado en la variable de la tabla. –
Bueno, me refiero a todo lo que haces * a la base de datos * - Supongo que asumí que era obvio que las variables no se ven afectadas por las transacciones, aunque supongo que es un poco menos intuitivo con variables de tabla que variables escalares. – Blorgbeard
¿Qué sucede si el SP llamado dentro de las llamadas de transacción externas confirma la transacción? ¿Se retrotraerá la transacción interna si la transacción externa llama a la reversión después de que se haya comprometido el interno? – holaSenor