2008-09-18 27 views
25

¿Alguien sabe cómo SQL Server determina que se ejecutan los disparadores de órdenes (del mismo tipo, es decir, antes de los desencadenadores). Y hay alguna forma de cambiar esto para poder especificar el orden que quiero. Si no, porque no.Disparos de SQL Server - orden de ejecución

Gracias.

Respuesta

2

El orden lo establece el servidor sql, lo único que puede hacer es usar un sistema sp (sp_settriggerorder) para establecer qué disparador disparará primero y cuál disparará al último.

Más allá de configurar el primer y último activador para disparar, no puede modificar ni indicar qué orden usará el servidor sql. Por lo tanto, querrá construir sus desencadenantes para que no confíen en el orden en que se dispararon. Incluso si determina el orden en el que disparan hoy, puede cambiar mañana.

Esta información se basa en Sql Server 2000, sin embargo, no creo que 2005/2008 actúe de manera diferente a este respecto.

4

Utilice sp_Settriggerorder procedimiento almacenado, puede definir el orden de ejecución del disparador.

sp_settriggerorder [ @triggername = ] ‘[ triggerschema. ] triggername’ 
, [ @order = ] ‘value’ 
, [ @stmttype = ] ’statement_type’ 
[ , [ @namespace = ] { ‘DATABASE’ | ‘SERVER’ | NULL } ] 

El segundo parámetro, “orden” puede tomar tres valores que significa que se puede tener en cuenta hasta a tres factores desencadenantes.

  1. Primera - gatillo se dispara primero
  2. Última - gatillo se dispara última
  3. Ninguno - gatillo se dispara en orden aleatorio.
1

Utilice este procedimiento almacenado del sistema:

sp_settriggerorder[@triggername = ] 'triggername', [@order = ] 'value', [@stmttype = ] 'statement_type' 
5

sp_settriggerorder sólo se aplica a los activadores AFTER.

4

Puede garantizar qué disparador se dispara primero, qué disparador se dispara al último y cuáles dispara en el medio usando sp_settriggerorder. Si necesita sincronizar más de tres, no parece posible en SQL Server 2005.

Aquí está una muestra tomada de here (El artículo enlazado tiene mucha más información).

sp_settriggerorder [ @triggername = ] ‘[ triggerschema. ] triggername’ 
, [ @order = ] ‘value’ 
, [ @stmttype = ] ’statement_type’ 
[ , [ @namespace = ] { ‘DATABASE’ | ‘SERVER’ | NULL } ] 
10

Si tu en el punto de tener que preocuparse por las órdenes de disparo, entonces, que realmente debe dar un paso atrás y considerar lo que está tratando de hacer y si no hay una mejor manera de hacerlo. El hecho de que esto no sea algo fácil de cambiar debería estar diciéndote algo.

disparadores siempre parece una buena solución real, y en el lugar correcto que son de gran valor, pero el precio es alto, es muy fácil crear pesadillas de depuración con ellos. He perdido muchas horas en el pasado al intentar depurar algún oscuro comportamiento de la base de datos solo para encontrar que la causa está oculta en un desencadenante pasado por alto.

17

Usando SetTriggerOrder está muy bien, pero si su código depende de una secuencia específica de ejecución, por qué no envuelva todos los factores desencadenantes en los procedimientos almacenados, y tienen la primera llamada de la segunda, la segunda llamada al tercero, etc.

Luego simplemente tiene que ejecutar la primera en el desencadenador.

Alguien en el futuro estará agradecido de que no tuvieron que buscar en una tabla del sistema para determinar una secuencia de ejecución personalizada.

+7

Generalmente, no hacemos esto porque no tenemos acceso fácil a los pseudotables Inserted and Deleted en los procedimientos almacenados. – mwigdahl

+0

El orden de ejecución puede ser interesante sin dependencia ... – Paul

14

Puede usar sp_settriggerorder para definir el orden de cada activador en una tabla.

Sin embargo, yo diría que sería mucho mejor tener un disparador único que haga varias cosas. Esto es particularmente por lo que si el orden es importante, ya que esa importancia no será muy obvia si tiene múltiples factores desencadenantes. Imagínese que alguien intenta respaldar la base de datos meses/años en la pista. Por supuesto, es probable que existan casos en los que necesite tener múltiples factores desencadenantes o que realmente sea un mejor diseño, pero comenzaría a suponer que debería tener uno y trabajar desde allí.

1

Una declaración millones de dólares en este contexto -

sp_settriggerorder: Especifica el desencadenadores AFTER que se disparan primero o el último . Los desencadenadores DESPUÉS que se disparan entre el primer y el último activador se ejecutan en un orden no definido.

Fuente: MSDN

2

Usar este:

Por ejemplo:

USE AdventureWorks; 
GO 
EXEC sys.sp_settriggerorder @triggername = N'', -- nvarchar(517) 
    @order = '', -- varchar(10) 
    @stmttype = '', -- varchar(50) 
    @namespace = '' -- varchar(10) 

la primera y última activadores deben ser dos diferentes factores desencadenantes.

Primero: el disparador se activa primero.

Último: el disparador se activa al último.

Ninguno: el disparador se dispara en un orden indefinido.

Y ver este enlace para el valor de @stmttype: DDL Events

Y para @namespace = { 'base de datos' | 'SERVIDOR' | NULL} y para obtener más información, consulte: DDL Triggers

Cuestiones relacionadas