2009-02-09 24 views
28

Imagine el siguiente escenario:transacciones anidadas en SQL Server

estoy usando SQL Server 2005. Tengo una transacción que está llamando, entre otras sentencias SQL, un procedimiento almacenado que también tiene una transacción dentro. La transacción externa a veces falla y se revierte después de que se llama al procedimiento almacenado y se confirma con éxito.

Mi pregunta es, ¿también se revierte la transacción del procedimiento almacenado?

Respuesta

36

Con una transacción anidada, una confirmación no escribe ningún cambio en el disco, a excepción de la transacción de nivel superior. Una reversión, sin embargo, funciona independientemente del nivel de la transacción, por lo que sí, retrotraerá la transacción interna.

+6

Rollback deshacer las transacciones se -todos-, no sólo la anterior. EG: http://www.emoreau.com/Entries/Articles/2011/02/EricMoreau1.gif –

+4

@ Pure.Krome es correcto. Las transacciones anidadas * * no harán lo que quieras. Vea la serie [SQL Server Myth a Day] (http://www.sqlskills.com/blogs/paul/post/A-SQL-Server-DBA-myth-a-day-%282630%29-nested-transactions- are-real.aspx) –

+0

Confirmación: http://technet.microsoft.com/en-us/library/ms189336(v=sql.90).aspx – Vadzim

2

Sí, se revertirá el procedimiento almacenado.

Aquí es el flujo general de su código:

BEGIN TRY 

    BEGIN TRANSACTION 

    EXEC SotredProcedureName 

    --Do some other activity 

    COMMIT TRANSACTION 
END TRY 
BEGIN CATCH 

    --IF an error occurs then rollback the current transaction, which includes the stored procedure code. 
    ROLLBACK TRANSACTION 

END CATCH 

Cheers, John

7

Absolutamente sí, la transacción de nivel superior será propietaria de todos los cambios de datos hasta que se confirme o se retrotraiga.

Sin embargo, le recomiendo que piense detenidamente sobre el modelo de transacción. Cuantos más escenarios existan en su sistema, mayor será su exposición a problemas de bloqueo. También aumenta el gasto computacional del procedimiento.

Es notable la frecuencia con la que, al racionalizar SQL, encuentro que las transacciones se han implementado donde simplemente no son necesarias. Lo aliento a usted (y a cualquier persona que trabaje con transacciones) a pensar cuidadosamente sobre por qué los está utilizando en cada contexto y qué sucedería si la transacción no se implementara. ¡Solo vale mi 2c!

1

He intentado con begin tran y commit dentro del procedimiento almacenado, dicen usp_test.
Exec estos sp con alguna otra consulta de la siguiente manera

update x set name='xxx' 
select * from x---contains 'xxx' 
begin tran 
update x set name='yyy' 
select * from x---contains 'yyy' 
exec usp_test 
select * from x---contains 'zzz' inside the sp 
rollback tran 

Mientras se ejecuta el nombre de la consulta anterior en la tabla x debe ser 'xxx' no es 'zzz' desde la primera tran comenzar incluso el rollback tran sp cometió.
Por lo tanto, primero comience a realizar los cambios en los datos.

Cuestiones relacionadas