Üblicherweise sind bei entfernten Datenbanken dieselben Trigger wie bei der konsolidierten Datenbank definiert.
Standardmäßig repliziert SQL Remote die Aktionen nicht, die von Triggern durchgeführt werden. Wenn eine Aktion, die einen Trigger in der konsolidierten Datenbank auslöst, in der entfernten Datenbank repliziert wird, erfolgt eine automatische Auslösung des mehrfach vorhandenen Triggers in der entfernten Datenbank. Dadurch werden Berechtigungsprobleme verhindert und sichergestellt, dass keine Aktion zweimal eintritt. Es gibt einige Ausnahmen zu dieser Regel.
RESOLVE UPDATE-Trigger replizieren Die von der Konfliktlösung oder den RESOLVE UPDATE-Trigger durchgeführten Aktionen werden von einer konsolidierten Datenbank an alle entfernten Datenbanken repliziert, einschließlich jene entfernte Datenbank, welche die Nachricht versendet hat, die den Konflikt erstellt hat. Weitere Hinweise finden Sie unter Standardlösung für Aktualisierungskonflikte.
Replikation von BEFORE-Triggern Die Aktionen eines BEFORE-Triggers, der eine Zeile, die aktualisiert wird, ändert, werden vor den UPDATE-Anweisungsaktionen repliziert.
So würde zum Beispiel ein BEFORE UPDATE-Trigger, der eine Zählungsspalte in der Zeile erhöht, um die Anzahl der Aktualisierungen einer Zeile zu protokollieren, eine doppelte Zählung bewirken, wenn er repliziert wird, da der BEFORE UPDATE-Trigger in der entfernten Datenbank ausgelöst wird, wenn die UPDATE-Anweisung repliziert wird.
Ein BEFORE UPDATE-Trigger, der eine Spalte auf den Zeitpunkt der letzten Aktualisierung setzt, erhält auch den Zeitpunkt, an dem die UPDATE-Anweisung repliziert wird.
Um dieses Problem zu vermeiden, müssen Sie sicherstellen, dass in der Subskribenten-Datenbank der BEFORE UPDATE-Trigger nicht vorhanden ist beziehungsweise die replizierte Aktion nicht ausführt.
Um beim Versenden von Nachrichten alle Triggeraktionen zu replizieren, verwenden Sie die Option -t beim Nachrichtenagenten (dbremote). Weitere Hinweise finden Sie unter Nachrichtenagent (dbremote).
Wenn Sie die Option -t verwenden, achten Sie darauf, dass die Triggeraktionen in entfernten Datenbanken nicht zweimal durchgeführt werden: einmal wenn die replizierten Triggeraktionen angewendet werden und einmal wenn der Trigger in der entfernten Datenbank ausgelöst wird.
Um sicherzustellen, dass Triggeraktionen nicht zweimal durchgeführt werden, verwenden Sie eine der folgenden Optionen:
Binden Sie den Hauptteil des Triggers in eine Anweisung IF CURRENT REMOTE USER IS NULL ... END IF ein.
Setzen Sie die SQL Anywhere-Option fire_triggers für den SQL Remote-Benutzernamen auf "Off". Weitere Hinweise finden Sie unter fire_triggers-Option [Kompatibilität].
Wenn eine Publikation nur eine Teilmenge einer Datenbank umfasst, kann sich ein Trigger in der konsolidierten Datenbank auf Tabellen oder Zeilen beziehen, die in der konsolidierten Datenbank vorhanden sind, nicht aber in den entfernten Datenbanken. Wenn solch ein Trigger in der entfernten Datenbank ausgelöst wird, treten Fehler auf. Um diese Fehler zu vermeiden, verwenden Sie eine IF-Anweisung, um die Triggeraktionen bedingt zu machen, sowie:
Machen Sie die Aktionen des Triggers vom Wert von CURRENT PUBLISHER abhängig. Weitere Hinweise finden Sie unter CURRENT PUBLISHER-Spezialwert.
Machen Sie die Aktionen des Triggers davon abhängig, dass die object_id-Funktion nicht NULL zurückgibt. Die object_id-Funktion nimmt eine Tabelle oder ein anderes Objekt als Argument und gibt die ID-Nummer dieses Objekts zurück, oder NULL, wenn das Objekt nicht existiert. Weitere Hinweise finden Sie unter Systemfunktionen.
Machen Sie Aktionen des Triggers von einer SELECT-Anweisung abhängig, die ermittelt, ob die Zeilen vorhanden sind.
Standardmäßig extrahieren das Extraktionsdienstprogramm (dbxtract) und der Assistent zum Extrahieren einer Datenbank die Triggerdefinitionen.
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |