Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » SQL Remote » SQL Remote-Replikationsplanung » SQL Remote-Replikation planen und einrichten » Aktualisierungskonflikte » Benutzerdefinierte Konfliktlösung mit Trigger

 

Inventurkonflikte lösen

Nehmen wir als Beispiel das Lagerhaussystem eines Produzenten für Sportartikel. Es gibt eine Tabelle mit Produktinformationen, in der eine Quantity-Spalte die Anzahl der einzelnen Produkte auf Lager enthält. Eine Aktualisierung in dieser Spalte würde typischerweise die Menge an Lagergütern verringern oder sie im Falle einer frischen Lieferung erhöhen.

Ein Handelsvertreter, der mit einer entfernten Datenbank arbeitet, gibt eine Bestellung ein, wodurch der Bestand an bestimmten T-Shirts von 28 auf 23, also um fünf, verringert wird. Bevor diese Aktualisierung an die konsolidierte Datenbank repliziert wird, erhält ein anderer Handelsvertreter 40 T-Shirts retourniert. Dieser Handelsvertreter gibt diese Rückgabe in seine entfernte Datenbank ein und repliziert die Änderungen an die konsolidierte Datenbank im Lagerhaus, wodurch 40 der Quantity-Spalte hinzugefügt werden, was 68 ergibt.

Die erste Aktualisierung fügt der Quantity-Spalte 40 hinzu.

Der Lagerhaus-Eintrag wird der Datenbank hinzugefügt. Die Quantity-Spalte zeigt, dass es nun 68 T-Shirts auf Lager gibt. Wenn die Aktualisierung des ersten Handelsvertreters eintrifft, entsteht ein Konflikt: SQL Anywhere erkennt, dass die Aktualisierung von 28 auf 23 lautet, der aktuelle Wert der Spalte jedoch 68 beträgt.

Standardmäßig setzt sich die aktuellere Aktualisierung durch, sodass die Inventargröße fälschlicherweise auf 23 gesetzt wird.

Nicht korrekte Konfliktlösung: Die zweite Aktualisierung überschreibt fälschlicherweise die erste Aktualisierung.

In diesem Fall sollte der Konflikt durch das Zusammenzählen der Änderungen in der Inventarspalte gelöst werden, um das Endergebnis zu berechnen, damit der endgültige Wert von 63 in die Datenbank eingetragen wird.

Korrekte Konfliktlösung: Die zweite Aktualisierung ändert die erste Aktualisierung.
Die Lösung implementieren

Ein geeigneter RESOLVE UPDATE-Trigger in dieser Situation würde die Veränderungen aus den zwei Aktualisierungen addieren. Zum Beispiel:

CREATE TRIGGER resolve_quantity
 RESOLVE UPDATE OF Quantity
 ON "DBA".Products
 REFERENCING OLD AS old_name
  NEW AS new_name
  REMOTE AS remote_name
 FOR EACH ROW
 BEGIN
   SET new_name.Quantity = new_name.Quantity
                        + old_name.Quantity
                        - remote_name.Quantity
 END;

Dieser Trigger addiert die Differenz zwischen dem alten Wert in der konsolidierten Datenbank (68) und dem alten Wert in der entfernten Datenbank, als die ursprüngliche UPDATE-Anweisung ausgeführt wurde (28), zu einem neuen Wert, der versendet wird, bevor die UPDATE-Anweisung implementiert wird. Daher wird new_name.Quantity 63 (= 23 + 68 - 28), und dieser Wert wird in die Quantity-Spalte eingegeben.

Die Konsistenz wird in der entfernten Datenbank folgendermaßen gewahrt:

  1. Die ursprüngliche entfernte UPDATE-Anweisung änderte den Wert von 28 auf 23.

  2. Der Eintrag des Lagerhauses wird in die entfernte Datenbank repliziert, was allerdings scheitert, da der alte Wert nicht der ist, der erwartet wurde.

  3. Die Änderungen durch den RESOLVE UPDATE-Trigger werden in die entfernte Datenbank repliziert.