Hace una reversión dentro de un INSERTAR DESPUÉS o ACTUALIZAR DESPUÉS del desenganche de la transacción completa

Question

Hace una reversión dentro de un INSERTAR DESPUÉS o una ACTUALIZACIÓN DESPUÉS del desencadenante revertir la transacción completa o solo la fila actual que es la razón para desencadenar, y es lo mismo con Commit?

Traté de verificarlo a través del código de mi proyecto actual que usa MSTDC para las transacciones, y parece como si la transacción completa hubiera sido cancelada.

Si una reversión en el desencadenador retrotrae la transacción completa, ¿hay alguna solución para restringirla solo a las filas actuales?

que encuentre un enlace de sybase en esto, pero no hay nada en el servidor SQL

Answer 1

Sí, va a deshacer toda la transacción.

Todo está en el docs (ver Comentarios). Tenga en cuenta el comentario que he enfatizado, ¡eso es muy importante, diría!

Si una transacción ROLLBACK se emite en un disparador:

Todas las modificaciones de datos realizadas a ese punto en la transacción actual se deshacen, incluyendo cualquier hecha por el gatillo.

El desencadenador continúa ejecutando las sentencias restantes después de la instrucción ROLLBACK. Si alguna de estas instrucciones modifica datos, las modificaciones no se revierten. La ejecución de estas sentencias restantes no desencadena disparadores anidados.

Las declaraciones en el lote después de la instrucción que activó el desencadenador no se ejecutan.

Answer 2

Cualquier comando de reversión revertirá todo hasta que @@ trancount sea 0 a menos que especifique algunos puntos de guardado y no importa dónde coloque el comando rollback tran.

La mejor manera es mirar el código una vez más y confirmar el requisito de negocio y ver por qué necesita una retrotracción en el desencadenante?

Answer 3

Como ya le han informado, el comando ROLLBACK no se puede modificar/sintonizar para que solo retrotraiga las declaraciones emitidas por el desencadenador.

Si necesita una forma de "retrotraer" las acciones realizadas solo por el desencadenante, puede como una solución temporal, considere modificar su desencadenador de tal forma que antes de realizar las acciones, el desencadenador se asegure de que esas acciones no producir situaciones excepcionales que causarían la reversión de toda la transacción.

Por ejemplo, si su activador inserta filas, agregue una marca para asegurarse de que las nuevas filas no violen, p.restricciones únicas (o restricciones de clave externa), algo como esto:

IF NOT EXISTS (
    SELECT * 
    FROM TableA 
    WHERE … /* a condition to test if a row or rows you are about 
       to insert aren't going to violate any constraint */ 
) 
BEGIN 
    INSERT INTO TableA … 
END; 

O, si su gatillo elimina filas, compruebe si no trata de eliminar filas referenciadas por otras tablas (en cuyo caso normalmente se necesita saber de antemano qué tablas Might referencia las filas):

IF NOT EXISTS (
    SELECT * FROM TableB WHERE … 
) 
AND NOT EXISTS (
    SELECT * FROM TableC WHERE … 
) 
AND … 
BEGIN 
    DELETE FROM TableA WHERE … 
END 

Del mismo modo, lo que se necesita para hacer comprobaciones para instrucciones de actualización, si los hubiere.