Ejecución de desencadenadores DML

Actualizado: 5 de diciembre de 2005

Los desencadenadores AFTER no se ejecutan nunca si se produce una infracción de restricción; por tanto, no se puede utilizar estos desencadenadores para ningún procesamiento que pueda impedir infracciones de restricciones.

Los desencadenadores INSTEAD OF se ejecutan en lugar de las acciones desencadenadoras. Estos desencadenadores se ejecutan una vez creadas las tablas inserted y deleted que reflejan los cambios realizados en la tabla base, pero antes de que se lleve a cabo cualquier otra acción. Se ejecutan antes que las restricciones, de manera que se pueden realizar las tareas de procesamiento previo que complementan a las acciones de restricción.

Si un desencadenador INSTEAD OF definido en una tabla ejecuta una instrucción contra la tabla que normalmente volvería a activar el desencadenador INSTEAD OF, éste no se llama de forma recursiva. En su lugar, la instrucción se procesa como si la tabla no tuviera un desencadenador INSTEAD OF e inicia la cadena de operaciones de restricción y ejecuciones de desencadenadores AFTER. Por ejemplo, si para una tabla se define un desencadenador DML como INSTEAD OF INSERT, y éste ejecuta una instrucción INSERT en la misma tabla, la instrucción INSERT ejecutada por el desencadenador INSTEAD OF no vuelve a llamar al desencadenador. La instrucción INSERT ejecutada por el desencadenador inicia el proceso que realiza las acciones de restricción y activa cualquier desencadenador AFTER INSERT definido para la tabla.

Si un desencadenador INSTEAD OF definido en una vista ejecuta una instrucción en la vista que normalmente volvería a activarlo, no se llamará al desencadenador de forma recursiva. En su lugar, la instrucción se resuelve a modo de modificaciones en las tablas base subyacentes de la vista. En este caso, la definición de la vista debe cumplir todas las restricciones para una vista actualizable. Para obtener una definición de vistas actualizables, vea Modificar datos mediante una vista. Por ejemplo, si para una tabla se define un desencadenador DLM como INSTEAD OF UPDATE y éste ejecuta una instrucción UPDATE que hace referencia a la misma vista, la instrucción UPDATE, que ejecuta el desencadenador INSTEAD OF, no vuelve a llamar al desencadenador. La instrucción UPDATE que ejecuta el desencadenador se procesa en la vista, como si ésta no tuviera un desencadenador INSTEAD OF. Las columnas modificadas por la instrucción UPDATE deben resolverse en una única tabla base. Cada vez que se modifica una tabla base subyacente se inicia la cadena para aplicar restricciones y activar los desencadenadores AFTER definidos para la tabla.

La sobrecarga de rendimiento de los desencadenadores DLM suele ser baja. El tiempo necesario para ejecutar un desencadenador DLM se dedica principalmente a hacer referencia a otras tablas, que pueden encontrarse en la memoria o en el dispositivo de la base de datos. Las tablas deleted e inserted se encuentran siempre en la memoria. La ubicación de otras tablas a las que hace referencia el desencadenador determina el tiempo que dura la operación.

[!NOTA] No es recomendable utilizar cursores en los desencadenadores DLM debido al impacto potencialmente negativo en el rendimiento. Utilice lógica basada en conjuntos de filas en lugar de cursores para diseñar desencadenadores DLM que afecten a varias filas.

Ejecución de desencadenadores DML y vistas con particiones

En SQL Server 2005, el modo en que los desencadenadores UPDATE y DELETE se activan en las tablas subyacentes de una vista con particiones ha cambiado con respecto a la forma en que se activan en SQL Server 2000. En SQL Server 2000, cuando una instrucción UPDATE o DELETE se emite en una vista con particiones, local o distribuida, cualquier desencadenador UPDATE o DELETE que esté definido en las tablas base de la vista se activa. Esto incluye a los desencadenadores en tablas que no se ven afectados por la operación de actualización o eliminación. En SQL Server 2005, un desencadenador UPDATE o DELETE sólo se activa si la tabla base en la que está definido el desencadenador se ve afectada por la operación de actualización o eliminación. Este comportamiento es el mismo para los desencadenadores AFTER e INSTEAD OF.

Por ejemplo, consideremos una vista con particiones PV que se compone de campos de las tablas T1 y T2. Además, las tablas T1 y T2 tienen desencadenadores UPDATE definidos en las mismas. En SQL Server 2000, una instrucción UPDATE emitida en PV que sólo afecta a las filas de T1 hace que se activen los desencadenadores UPDATE en T1 y en T2. En SQL Server 2005, sólo se activa el desencadenador UPDATE que está definido en T1.

En la siguiente tabla se resumen los cambios de comportamiento.

Operaciones de inserción, actualización o eliminación en una vista local con particiones

Operaciones de inserción, actualización o eliminación en una vista distribuida con particiones

Vea también

Conceptos

Usar las tablas inserted y deleted
Restricciones de integridad referencial en cascada
Usar desencadenadores anidados

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios