Cuando haga desencadene fuego y cuando no lo hacen ellos

Question

pregunta bastante general en cuanto a los factores desencadenantes en el servidor SQL 2005.

¿En qué situaciones se disparan los desencadenantes de mesa y qué situaciones no son?

Cualquier ejemplos de código para demostrar serían grandes.

Estoy escribiendo una auditoría de bases de datos basadas y sólo quieren ser conscientes de las situaciones que podrían no disparar los factores desencadenantes que he creado para actualizar, borrar e insertar en mis tablas.

Un ejemplo de lo que quiero decir,

UPDATE MyTable SET name = 'test rows' WHERE id in (1, 2, 3);

La siguiente declaración sólo se dispara el gatillo una vez al día.

Answer 1

¿Cuándo quiere que el fuego?

CREATE TRIGGER AFTER ACTION

que se ejecuta después de la acción (insert update delete) que se cometen. INSTEAD OF dispara el gatillo en su lugar de la acción.

Una de las mayores trampas con gatillos es que se disparan cada vez que se realiza una acción, incluso si se ven afectados ninguna fila . Esto no es un error, y es algo que le puede quemar muy rápidamente si no se tiene cuidado.

Además, con factores desencadenantes, podrás utilizar las mesas de inserted y deleted. filas actualizadas se enumeran en ambos. Esto arroja un montón de gente fuera, ya que no están acostumbrados a pensar en un update como delete continuación insert.

La documentación de MSDN en realidad tiene un bonito debate en profundidad acerca de cuándo desencadena el fuego y qué efecto tienen aquí .

Answer 2

En 2008 se puede utilizar construido en la Cambio de captura de datos

También hay un buen número de situaciones en las que los desencadenantes no se activan, por ejemplo:

· se deja caer una mesa.

· se trunca una tabla.

· Ajustes para desencadenadores anidados y / o recursivas impiden un disparador se dispare.

· datos es a granel, disparadores sin pasar cargados.

Answer 3

  

La siguiente declaración sólo se dispara el gatillo una vez al día.

Cualquier declaración de tipo de acción sólo se dispara el gatillo una vez, no importa cuántas filas se ven afectados, activadores deben ser escritos para manejar múltiples inserciones de fila / actualizaciones / eliminaciones.

Si el gatillo depende de una sola fila a la vez de estar en las pseudotables insertados o eliminados, se producirá un error. Y lo peor no va a producir un error, simplemente no afectará a todas las filas que desee que afecte lo hace el gatillo. No solucionar este problema a través de un bucle o un cursor en un disparador, cambiar la lógica de configuración basada. Un cursor en un disparador puede llevar toda su aplicación a un alto mientras una transacción de 500.000 procesos de registros y se bloquea la mesa durante horas.

inserciones masivas por pase desencadena a menos que se especifique de usarlos. Estar al tanto de esto porque si se les deja pasar por el gatillo necesitará código para asegurarse de lo que sucede en el gatillo también sucede después de la inserción masiva. O es necesario llamar a las inserciones masivas con la opción FIRE_TRIGGERS.

Answer 4

pensé que destacar desde el enlace de Eric registró una situación en la que lo haría un disparador se dispara:

  

A pesar de una instrucción TRUNCATE TABLE es en efecto un DELETE, no se puede activar un gatillo porque la operación no registra eliminaciones de filas individuales. Sin embargo, sólo los que tienen permisos sobre una mesa para ejecutar un TRUNCATE TABLE tiene por qué preocuparse por eludir inadvertidamente un desencadenador DELETE con una instrucción TRUNCATE TABLE.