|
Hallo!
Das wichtigste in K�rze:
Wenn eine Tabelle einen Trigger hat, werden
neue Werte in der Satemtabelle "inserted" und alte Werte in "deleted"
gespeichert. Ein INSERT, schreibt in "inserted", ein DELETE in "deleted" und ein
UPDATE schreibt die vorherigen Werte in "deleted" und die neuen in "inserted".
Diese Systemtabellen sind tempor�re Tabellen und stehen nur in der
Triggerfunktion zur Verf�gung.
Sowohl in "inserted" als auch in "deleted"
k�nnen mehrere Datens�tze stehen, n�mlich genau dann, wenn mehrere Datens�tze
auf einmal eingef�gt, modifiziert oder gel�scht werden. Ein "DECLARE @myID int;
SELECT @myID = myField FROM inserted" klappt also nur, wenn genau ein Datensatz
eingef�gt wird, bzw. modifiziert wird.
Die Funktion "COLUMNS_UPDATED()" liefert
innerhalb eines Triggers ein Bitmuster der Spalten, die eingef�gt oder
modifiziert wurden. Wurde beispielsweise die 1. 4. und 5. Spalte modifiziert,
ergibt die Funktion den Wert 1 + 8 + 16 = 25. Das braucht man vor allem, um
Trigger-Endlosschleifen andere "Triggerunf�lle" zu vermeiden.
Mit Triggern kannst Du sehr einfach
Gesch�ftsregeln erstellen. Wenn in Deinem Fall eine Rubrik modifiziert wird,
kannst Du in etwa folgendes machen:
CREATE TRIGGER ... ON ...
FOR INSERT, UPDATE, DELETE
AS
-- alte Werte
UPDATE ergebnisse
SET wert =
wert - 1
WHERE rubrik IN (SELECT
rubrik FROM deleted)
-- nicht ben�tigte Rubriken
l�schen
DELETE FROM
ergebnisse
WHERE rubrik NOT IN
(SELECT rubrik FROM eingaben)
-- neue Werte, vorhandene
Rubriken
UPDATE ergebnisse
SET wert =
wert + 1
WHERE rubrik IN (SELECT
rubrik FROM ergebnisse)
AND
rubrik IN (SELECT rubrik FROM inserted)
-- neue Werte, neue
Rubriken
SELECT rubrik, 1
INTO
ergebnisse
FROM
inserted
WHERE rubrik NOT IN
(SELECT rubrik FROM ergebnisse)
Aus Performanzgr�nden kannst Du das noch in
"IF COLUMNS_UPDATED() = ..." kapseln und die WHERE-Klauseln mit EXISTS-Abfragen
optimieren.
Gehe lieber immer davon aus, dass "inserted"
und "deleted" mehrere Datens�tze enthalten. Irgendwann trifft das ganz bestimmt
mal zu und sei es durch einen Import, eine Replikation oder durch das L�schen
einer Tabelle. Die Methode mit "DECLARE @myID int; SELECT @myID = rubrik FROM
inserted" klappt nur, wenn immer genau 1 Satz eingef�gt oder modifiziert wird.
Machst Du dann doch irgendwann mal z. B. ein UPDATE �ber mehrere Datens�tze,
funktioniert der Trigger nicht mehr.
Wenn Du unbedingt eine andere Prozedur aus
der Triggerprozedur heraus aufrufen willst oder musst, dann musst Du eine
CURSOR-Variable verwenden und die Datens�tze aus "inserted" und "deleted" in
eine Schleife abarbeiten. Ich versuche immer, das zu vermeiden.
Ganz sicher wirst Du in Deiner
Ergebnistabelle nicht wie hier im Beispiel einfach nur z�hlen, denn dazu
brauchst Du ja keine Trigger sondern lediglich eine View, die die Ergebnisse
st�ndig neu berechnet oder in einer tempor�ren Tabelle ablegt. Um die
Ergebnistabelle mit anderen Werten aus der Eingabetabelle zu modifizieren,
kannst Du "inserted" und "deleted" mit der Ergebnistabelle verkn�pfen (INNER
JOIN). Je nach Datenmenge und H�ufigkeit von Ver�nderungen kann ein Trigger oder
eine View sinnvoller sein. Ich berechne Werte eigentlich lieber in VIEWs, da
diese auch in Access funktionieren; Trigger gibt es nicht in allen
Datenbanken.
Freundliche Gr��e | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp |
Title: Nachricht
