war ne ganze Menge 'neuen' Stoff f�r mich.
Herzlichen Dank.
F�rchte allerdings nur ein Viertel davon
verstanden zu haben. Kommt vielleicht noch. :-) da guter Hoffnung bin.
Habe anfangs mit ner View gearbeitet. Leider
kamen bereits nach ca. 50 eintr�gen in den Eingabetabellen Timeouts. Daher gibt
es nun diese Ergebnistabelle auf die dann andere SP's zugreifen die wiederum
durch Excel XLA's oder ASP aufgerufen werden.
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
Joachim van de Bruck
Mist zu fr�h gefreut. :-(
Beim L�schen funktioniert das allerdings
nicht wie es soll.
Wie bekomme ich @myID von einem
Datensatz heraus der gerade gel�scht wurde. Sonst bleiben mir 'Leichen im
Keller'
DECLARE @myID int
SELECT @myID = myFKfield FROM
Eingabetabelle
EXEC myStoredProc @myID
Hintergrund ist der, das es eine
Eingabetabelle gibt, auf der der Trigger liegt und dieser �ber die SP
Ergebnisse in die Ergebnistabelle berechnet und schreibt. Wenn nun in der
Eingabetabelle Werte einer Rubrik ge�ndert werden, sollen alle zugeh�rigen
Ergebnisse der Rubrik in der Ergebnistabelle neu geschrieben werden. So weit
nun Dank Joachim kein Problem mehr.
Was aber wenn der letzte Wert einer
Rubrik oder dieselbe(1:n) g�nzlich gel�scht wird? --> Dann greift
das Select im Trigger ins leere und die falsche ID wird �bergeben. *�tz*
Kennt sich da jemand aus und kann mir helfen?
Alternativ: Nachts nen Skript laufen
lassen was die 'Leichen' sucht is doch nicht wirklich ne L�sung, oder?
Viele Gr��e von der K�ste.
Andreas
Au ja Danke. ;-))
Manches geht auch
wirklich einfacher als man denkt/vermutet.
Viele Gr��e von der K�ste
Andreas
>> bin leider immer
noch auf der Suche nach der L�sung wie ich einer durch
nen Trigger aufgerufenen Procedure einen Parameter mitgeben
kann. Wenn ein Datensatz ver�ndert
wird, soll der im Datensatz gespeicherte Fremdkey (Feld: FK) der
durch den Trigger aufgerufenen Procedure �bergeben werden. <<
Die eben bearbeiteten Daten stehen
in den Tabellen
inserted = beim Einf�gen,
beim �ndern (der neue Datensatz)
deleted = beim �ndern (der
alte Datensatz), beim L�schen
Also mu�te Du nur eine lokale
Variable erzeugen und die mit dem
Wert f�llen. In etwa so:
DECLARE @myID int
SELECT @myID = myFKfield FROM
inserted
EXEC myStoredProc @myID
Tsch��, Joachim
----Urspr�ngliche
Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12.
November 2002 17:27
An: ASP
Datenbankprogrammierung
Betreff: [aspdedatabase]
Trigger
Hallochen,
bin leider immer noch auf der Suche nach der L�sung wie ich
einer durch nen Trigger aufgerufenen Procedure einen
Parameter mitgeben kann.
Wenn ein Datensatz ver�ndert wird, soll der im Datensatz
gespeicherte Fremdkey (Feld: FK) der durch den Trigger aufgerufenen
Procedure �bergeben werden.
Hat jemand ne Idee f�r den SQL-Server 2000 und kann mir einen
Hinweis geben?
Danke schon mal.
Viele Gr��e von der K�ste
Andreas
| [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
| [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
| [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
| [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
| [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
| [aspdedatabase] als 