T-SQL trigger efekt změny před voláním jiný kód

hlasů
0

Mám tabulku, call pojďme je [mytable] , se pro vložení ignorovat, UPDATE trigger.

Spoušť je třeba vykonat uložené procedury, která bude dělat nějakou práci na základě změn provedených [moje_tabulka] . Nemohu přesunout kód uložené procedury je na spoušti.

Tak daleko, tak dobrý ... od spouštěče spustit po provedení změn, uložené procedury nemá potřebu přístupu k [vloží] nebo [smazáno] metatables.

Nicméně ... spoušť se musí změnit jeden další pole (a [LastModified] smalldatetime), takže uložená procedura může tato data použít v jeho zpracování. To je to , aby uložené procedury můžete vidět, co byl vložen / aktualizován ... postup může dělat řadu věcí na základě jiných záznamů, které nebyly zahrnuty v aktualizaci spuštění jej.

Problém je v tom, jestli můj spoušť změní [LastModified] , které budou buď dělat vůbec nic (pokud jsem rekurzivní spouštěče vypnutý), nebo to skončí dvakrát volání uložené procedury - jednou, protože původní vyvolávající změny a znovu kvůli mé změny [LastModified] .

Jak mohu získat kolem to tak (a) [LastModified] se aktualizuje s každou změnou a (b) uložená procedura je volána až poté, co to má přístup k nové hodnotě [LastModified] ?

Mám dva nápady přemýšlím, ale voní zábavné, takže jsem radši zjistit, jestli tam je přímější řešení.

Upravit:

Ok, tady jsou řešení jsem dosud, možná to pomůže diskusi:

1. Použití dvě spouště. Jeden z nich, se „místo“ spoušti by zvládnout aktualizaci uživatele záznamu a změní lastModified, ale vrátí se rychle v případě, že aktualizace přichází z SP (to může říct, na základě toho, co sloupky jsou upraveny). Ten druhý by byl „po“ trigger, který by volal EXEC. Toto pravidlo dostane aktualizace s sloupci lastModified již použita By the místo vzniku spoušť. Aspoň doufám, že to funguje.

2. Přesuňte ModifiedDate k jinému stolu. Tímto způsobem mohu mít jeden AFTER INSERT ignorovat / UPDATE trigger, že pouze v případě, že uživatel spustí INSERT ignorovat / UPDATE přidá záznam o auditu k druhému stolu a volá SP. SP by pak upravit další záznamy, které by způsobily spoušť znovu střílet, ale to by se rychle rozpoznat situaci a vrátit se, aniž by dělal více práce.

Nevýhodou prvního řešení je, že musím udržovat seznam sloupců ve spoušti, takže místo aktualizace vlastně dělá dílo určené k užití (protože jsem přidáním sloupce do seznamu ModifiedDate, nemohu jen INSERT IGNORE INTO tbl FROM vložena, musím zadat sloupce).

Položena 26/08/2009 v 23:26
zdroj uživatelem
V jiných jazycích...                            


2 odpovědí

hlasů
3

Už jste vyzkoušeli (LastModified) instrukci IF UPDATE?

CREATE TRIGGER XYZ ON MYTABLE 
FOR INSERT IGNORE , UPDATE 
AS 
BEGIN 
IF UPDATE(LastModified) 
  RETURN 
ELSE 
  BEGIN
    UPDATE MYTABLE SET LastModified = GETDATE() 
    FROM MYTABLE INNER JOIN INSERT IGNORE ED ON MYTABLE.ID = INSERT IGNORE ED.ID
    EXEC TheStoreProc
  END
END;
Odpovězeno 27/08/2009 v 02:53
zdroj uživatelem

hlasů
0

Nejsem si jistý, chápu tok, který popisuje. Je to:

  1. Záznam je aktualizován
  2. Aktualizace trigger proc se nazývá
  3. trigger aktualizuje LastModified pole
  4. trigger volá jiný proc

že by měly fungovat dobře, pokud je „jiný proc“ neaktualizuje stejné tabulky, které by rozehrávku spoušť znovu.

V případě, že „jiný proc“ se znovu aktualizuje tabulku, mohli byste přesunout tyto aktualizace do spoušti před voláním „jiný proc“.

Je to, že jakákoliv pomoc?

Odpovězeno 27/08/2009 v 03:07
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more