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