Oracle: Sich gegenseitig auslösende Trigger

[Mulder]

Ich habe das Problem, daß für eine Übergangszeit zwei Datenbankschemata parallel laufen sollen, die beide aktiv sind, d.h. einige Applikationen greifen noch auf das alte, die neueren auf das neue Schema zu.
Daher kommt es - vereinfacht - zu folgender Situation:

Trigger auf Tabelle A, daß bei Update ein entsprechendes Update von Tabelle B gemacht wird.
Trigger auf Tabelle B, daß bei Update ein entsprechendes Update von Tabelle A gemacht wird.

Leider scheint mir da jedoch eine Endlosschleife zu kommen.
Hier die beiden Trigger:

create or replace TRIGGER trg_sync_cul_update
 after update
 on core_user_login
 for each row
 begin
  update passwort_dev
    set passwort = :new.password
  where
   code = :old.user_id;
 end;

create or replace TRIGGER trg_sync_passwort_update
 after update
 on passwort_dev
 for each row
 begin
  update core_user_login
  set
   login = :new.name,
   password = :new.passwort
  where user_id = :new.code;
 end;

Damit kriege ich jedoch einen Oracle-Fehler, lt. Oracle-KB deswegen, weil Trigger A feuert B feuert A und Fehler, weil Tabelle A gerade geändert wird.

Ich habe einen Workaround, bei dem die Trigger sich per übergebenem Extra-Wert verständigen, aber dazu muß ich jeder beteiligten Tabelle ein Extra-Feld spendieren und es erscheint mir auch zu gefummelt...

Jemand einen Vorschlag?

[WMG]

Könnte ein Verbinden beider Datenbanken helfen? so benötigst Du nur einen Trigger, oder?

[Mulder]

Könnte ein Verbinden beider Datenbanken helfen? so benötigst Du nur einen Trigger, oder?

Wieso brauche ich dann nur einen?
Beide Tabellen liegen in der selben Serverinstanz, allerdings in unterschiedlichen Schemata, jedes Schema kann auf beide Tabellen zugreifen - IOW Du kannst davon ausgehen, daß es sich genau so verhält, als lägen beiden Tabellen im selben Schema.

[Michael Schröpl]

Hi,

Ich habe das Problem, daß für eine Übergangszeit zwei
Datenbankschemata parallel laufen sollen,

genau. ;-)

Im Ernst: Derjenige, der das befohlen hat, hat Dir Deine aktuelle
Situation eingebrockt.

Ich habe einen Workaround, bei dem die Trigger sich per übergebenem
Extra-Wert verständigen, aber dazu muß ich jeder beteiligten Tabelle
ein Extra-Feld spendieren und es erscheint mir auch zu gefummelt...

Deine Applikationen müssen in beide Tabellen schreiben dürfen, und
jede der beiden Tabellen hält ihren "Spiegel" aktuell. Soweit alles
okay.

Du mußt auch unbedingt verhindern, daß ein Trigger-Event als "Echo"
zurück kommt; Deine Trigger-Funktion kann jedoch m. E. auf nichts
anderes zurückgreifen als den aktuellen Record, um sich parametri-
sieren zu lassen, weil sie über einen impliziten Aufruf gestartet
wird, nicht über einen expliziten.

Das Problem ist, daß Du zwar verhindern kannst, daß _weitere_ Echos
kommen (denn wenn A von B wieder getriggert wird, kann der Trigger
nun leicht feststellen, daß er die Tabelle nicht mehr ändern muß
(weil ihr Inhalt bereits mit dem neuen Record übereinstimmt) und das
Ping-Pong-Spiel endet an dieser Stelle - Serve and Volley ;-), aber
genau das weiß der Oracle-Trigger-Mechanismus nicht und vermutet
schon an dieser Stelle die Endlosschleife.

Hast Du mal die Oracle-Hotline gefragt, ob man diese Ping-Pong-
Sicherung per Konfiguration abschalten kann?

Viele Grüße
      Michael