Nested Trigger Problem

[Jelly]

Ich habe ein Problem mit Nested Triggers. Und zwar modififiere ich in einem Update Trigger einer Tabelle A einen Record aus Tabelle B. B besitzt aber auch einen Trigger, der den Record aus Tabelle A updated. Sinn der Sache ist es 2 Datenfelder unter gewissen Bedingungen synchron zu halten. Das bedeutet also dass ein Trigger wieder den nächsten auslöst, bis die Tiefe von 32 Aufrufen erschöpft ist und die Transaction abgebrochen wird.

Ich weiss, eine Lösung wäre "Nested Triggers" für den Server gleich ganz auszuschalten. Das will ich aber vermeiden, weil ich nicht genau weiss ob da andere Dinge ins Rudern kommen. Deshalb die Frage, gibt es eine andere Möglichkeit, die 2 Datenfelder aus den 2 Tabellen automatisch synchron zu halten als Trigger? Oder kann man Nested Triggers für bestimmte Fälle ausschalten?

[mumu]

hmm du könntest trigger a mit nem execute immediate statement deaktivieren bevor du daten an der tabelle a änderst und eben danach wieder einschalten...

[alzaimar]

Wenn ich mir über Nebeneffekte eines Triggers nicht im Klaren bin (oder bei komplexen Daten gar nicht weiss, wo ich den Trigger ansetzen soll), dann lagere ich den Trigger in die Mittelschicht aus. Das ist zwar irgendwie blöd, hat aber bislang noch nicht zu Problemen geführt, da ich das Ganze in eine ADO-Transaktion kapsele. Bisher hats (*aufholzklopf*) immer gehalten:

Trigger sind schon eine knifflige Sache. Ich war mal ganz heiss drauf, dann wieder nicht. Mittlerweile mache ich es so:
Synchronisation der Metadaten in der Mittelschicht, wie oben beschrieben
Synchronisation von redundanten Lookuptabellen (dann gehen bestimmte Auswertungen schneller) im Server.

[marabu]

Tom, du brauchst doch nur ein Abbruchkriterium im Trigger zu definieren. Das Update der jeweils anderen Tabelle muss ja nur dann beauftragt werden, wenn sich die Werte in den beiden pseudo tables unterscheiden.

Grüße vom marabu

[Jelly]

Eine Mittelschicht gibts bei diesem Projekt leider nicht. Der Datenzugriff passiert noch direkt vom Client über die BDE an den SQL Server. Da jetzt noch was dran zu ändern halt ich für zu aufwendig.

Dann bliebe ja im Grunde noch Möglichkeit, die Datenfelder am Client zu synchronisieren. Das halt ich aber wiederum für haarig in einer Multiclient Umgebung.

Kann ich denn irgendwie im auslösenden Trigger eine globale Variable definieren, die ich im nächsten Trigger abrufen kann. Da hab ich bislang auch noch keine Möglichkeit gefunden. Aber damit könnt ich ja dann jeweils im Trigger entscheiden, ob die Befehle ausgeführt werden sollen oder nicht.

[Jelly]

Zitat:

Zitat von marabu

Tom, du brauchst doch nur ein Abbruchkriterium im Trigger zu definieren. Das Update der jeweils anderen Tabelle muss ja nur dann beauftragt werden, wenn sich die Werte in den beiden pseudo tables unterscheiden.

Das mach ich schon. Es wird das Datum in der Tabelle B auch nur dann geupdated, wenn es sich vom Wert aus Tabelle A (inserted) unterscheidet. Aber trotzdem kommt es zum Überlauf weil sich die Trigger gegenseitig aufrufen.

Abbruchbedingung ist auch ein Gedanke von mir (siehe vorheriger Beitrag), nur weiss ich nicht wie ich die Triggerübergreifend definieren kann.

[marabu]

Hi Tom,

wie muss ich mir die beiden Tabellen vorstellen?

SQL-Code:

tbla (id, datum, ...)
tblb (id, datum, ...)

Da muss es doch ein verbindendes Attribut geben. Und wie sind die Komplexitäten? Je mehr Info desto besser.

marabu

[Jelly]

Es sind 2 Tabellen (Property und Prozess), die mit einer 1:n Beziehung zusammenhängen, d.h. für jede Property kann es mehrere Prozesse geben. Beim Anlegen einer neuen Property wird in der Tabelle ein Prozessbeginn Datum festgelegt. Wenn es nun zu dieser Property erst GENAU EINEN Prozess gibt, so soll die Spalte PeriodBeginn aus Prozess immer mit dem Datum Prozessbeginn aus der Property synchron sein. Ändere ich eins von beiden Daten, so soll in der anderen Tabelle das Datum mit angepasst werden. Diese aber nur, solange es erst einen einzigen Prozess für die Liegenschaft gibt. Bei mehrern Prozessen dürfen die Daten unterschiedlich sein. Da ist auch der Grund, warum ich dieses Feld redundant für den ersten Prozess speichern muss. Es ist auch möglich, eine Property OHNE Prozess zu haben. Sonst würde ja im Prinzip ein Eintrag in der Prozess Tabelle genügen...

Hier mal die beiden Trigger der Tabelle Property und Prozess, die aber im Grund dasselbe machen. Dazu existiert noch eine View welche den PK der Property und des Prozesses liefert. HBedingung ist hier, dass die Property erst einen Prozess hat, sonst taucht sie nicht in der View auf.

Property Trigger:

SQL-Code:

CREATE TRIGGER trPropertyInsertUpdate ON [dbo].[Property] 
FOR INSERT, UPDATE
AS
declare @P_ID int
declare @PP_ID int
declare @HKAWarningWaitUntil datetime
declare @PP_PeriodEnd datetime

update PropProcess 
set PP_PeriodBegin = i.FirstProcessStart
from Inserted i 
left join PropProcess pp on pp.pp_property=i.ID
where i.ID in (Select P_ID from vwPropertiesWithOneProcess)
and i.FirstProcessStart is not null 
and pp.PP_PeriodBegin <> i.FirstProcessStart

Prozess Trigger:

SQL-Code:

CREATE TRIGGER trPropProcessSetFirstProcessStartInProperty ON [dbo].[PropProcess] 
FOR INSERT, UPDATE
AS

update Property 
set FirstProcessStart = i.PP_PeriodBegin
from Inserted i 
left join Property p on i.pp_property=p.ID
where i.pp_property in (Select P_ID from vwPropertiesWithOneProcess)
and i.pp_periodbegin is not null 
and i.PP_PeriodBegin <> p.FirstProcessStart

[marabu]

Hallo Tom,

auch wenn ich dein fachliches Problem nicht so ganz verstehe, das technische Problem sollte sich lösen lassen. Wenn du deinen Ansatz weiter verfolgen möchtest, dann musst du das von mir erwähnte Abbruchkriterium (Ungleicheit von deleted.firstprocessstart und inserted.firstprocessstart bei einem Update) noch einbauen.

Wenn FirstProcessStart nie NULL sein darf, dann könntest du ein entsprechendes constraint festlegen und dir die Prüfung in deiner WHERE Klausel sparen. Überhaupt solltest du vielleicht keinen Kmbi-Trigger für Insert und Delete verwenden - zumindest nicht solange bis die einzelnen Trigger ausgetestet sind.

Vielleicht liegt es an meinem mangelhaften Verständnis deiner Aufgabe, aber ich sehe da eine Differenzierung der Prozess-Tabelle in einen generischen und einen instanziierten Teil im Rahmen einer gen-spec-relation als sinnvoll an. Dadurch kann beim Insert einer property grundsätzlich ein generischer Prozess generiert werden, der das dann nicht mehr redundante Start-Datum aufnimmt und erst im späteren Verlauf zu einem echten Prozess ausgebaut werden. Um Trigger kommst du auch dabei nicht herum, aber die sollten dann nicht mehr so komplex sein - oder?

Gute Nacht.

marabu

[Jelly]

Hallo marabu,

danke für den ausführlichen Ausschweif. Ich habe nach genauer Überprüfung jetzt die Nested Triggers am Server ausgeschaltet, weil dies bislang an keiner Stelle genutzt wurde. Klappt also so ganz prima, und ich bin mittlerweilen auch der Meinung, dass nested Triggers einem ganz schön kopfzerbrechen machen können.

Warum es bei meinen Triggern überhaupt zu gegenseitigen Aufrufen kommt, ist mir allerdings immer noch nicht ganz klar. Ich hab doch die Bedingung drin, dass das Datum nur dann geupdatet wird, wenn es sich vom Datum der anderen Tabelle unterscheidet...

Die Dinger haben halt manchmal so ihr Eigenleben. Erinnert mich so bischen an Probleme in Delphi, wenn ich in OnChange Ereignisse Properties setzen will, und in der Setter Methode die Komponente wieder versuche zu füllen. Da hatte ich die Probleme dann auch schon. :zwinker: