Konflikterkennung und -berichterstellung für RDA

Der Remotedatenzugriff (Remote Data Access, RDA) in Microsoft SQL Server Compact 3.5 stellt einen eingeschränkten Mechanismus zur Konfliktberichterstellung für Zeilen bereit, die während eines Push-Vorgangs nicht auf dem Computer aktualisiert werden können, auf dem SQL Server ausgeführt wird.

Wichtig

Konflikt verursachende Zeilen sind im Remotedatenzugriff streng als Einfüge-, Aktualisierungs- und Löschvorgänge definiert, die aufgrund eines Fehlers beim Push von SQL Server Compact 3.5 in die SQL Server-Tabelle fehlschlagen. Von verschiedenen Benutzern vorgenommene Änderungen an Daten werden nicht als Konflikte betrachtet, wenn sie keine Fehler verursachen.

RDA stellt im Gegensatz zur Replikation zwar keinen speziellen Konfliktlöser bereit, SQL Server Compact 3.5 bietet jedoch eine Fehlertabelle, die alle Konflikt verursachenden Zeilen aufzeichnet. Sie können die Fehlertabelle als Teil der Pull-Methode angeben. Alle Fehler, die während des Push-Vorgangs auftreten, werden in dieser Fehlertabelle aufgezeichnet. Mithilfe der Fehlertabelle können Sie Anwendungen zum Verwalten der Konflikterkennung und -berichterstellung entwickeln.

An der SQL Server Compact 3.5-Datenbank vorgenommene Änderungen, für die ein Push zum Server ausgeführt wird, werden in der Reihenfolge angewendet, in der sie empfangen werden. Die SQL Server-Tabelle wird aktualisiert, um die vom letzten Benutzer vorgenommenen Änderungen wiederzugeben.

Ein Konflikt besteht in RDA, wenn für eine Zeile kein Push von SQL Server Compact 3.5 zu SQL Server ausgeführt werden kann. RDA unterstützt nur Nachverfolgung auf Zeilenebene. Deshalb werden, abhängig von den in einer Push-Methode ausgewählten Optionen, einige Zeilen erfolgreich gesendet, während andere fehlschlagen. Zum Nachverfolgen von Konflikten in RDA geben Sie TRACKINGON oder TRACKINGON_INDEXES in der Pull-Methode an.

Sie können Konflikte und Fehler vermeiden, wenn Sie nachverfolgte RDA-Tabellen verwenden, indem Sie Tabellen richtig filtern und beim Übertragen von Daten eine stabile Netzwerkverbindung verwenden.

Ursachen für das Auftreten von RDA-Konflikten

Änderungen an einer Zeile können auf dem Server aus folgenden Gründen nicht angewendet werden:

• RDA verfolgt Einfüge-, Aktualisierungs- und Löschvorgänge speziell für jede Zeile nach, die in der nachverfolgten Tabelle auf dem Gerät geändert wurde. Wenn eine Zeile auf dem Client eingefügt wird, die denselben Primärschlüsselwert hat wie eine Zeile, die ebenfalls auf dem Server in dieselbe Tabelle eingefügt wurde, schlägt deshalb der Push vom Client mit einem Fehler fehl, da der Einfügevorgang bereits stattgefunden hat.

• Wenn die Daten nicht für jeden Benutzer richtig partitioniert wurden, kann ein Benutzer eine Zeile löschen, während ein anderer Benutzer versucht, dieselbe Zeile zu aktualisieren.

• Das Senden von Zeilen zum Server kann auch fehlschlagen, was Fehler verursacht, wenn ein vorhergehender Push unterbrochen wurde. Beispielsweise beginnt ein Benutzer, ein Push zum Server für Daten auszuführen, die Einfügungen enthalten, und während des Push-Vorgangs wird die Netzwerkverbindung unterbrochen. Der Client zeigt eine Meldung an, dass der Push aufgrund des Verlustes der Netzwerkverbindung fehlgeschlagen ist. Die Änderungen wurden jedoch auf dem Server angewendet. Wenn die Netzwerkverbindung für den Client wiederhergestellt wird und der Benutzer versucht, einen zweiten Push für dieselben Daten auszuführen, können einige Zeilen nicht angewendet werden, weil diese während des ersten Push-Vorgangs eingefügt wurden. In diesem Fall sollte die Anwendung alle Fehler in der Fehlertabelle ignorieren, bei denen es sich um Fehler aufgrund eines doppelten Primärschlüssels basierend auf dem zweiten Push handelt.

Fehlertabellen

RDA verfolgt Datenkonflikte (Zeilen, die aufgrund eines Fehlers nicht auf den Server angewendet werden konnten) nach, indem die Fehler zurückgegeben und zusammen mit der betreffenden Zeile in einer Fehlertabelle in der SQL Server Compact 3.5-Datenbank gespeichert werden. Sie definieren diese Tabelle in der Pull-Methode. Falls später Fehler während eines Push-Vorgangs auftreten, werden diese in der Fehlertabelle gespeichert.

Wenn beim Verwenden der Push-Methode eine Zeile aufgrund eines Fehlers, z. B. wegen eines doppelten Primärschlüssels, nicht auf den Server angewendet werden kann, verweisen Sie zum Auflösen der Zeile auf den Namen der Fehlertabelle, die Sie ursprünglich in der Pull-Methode definiert haben. Die ErrorTableName-Eigenschaft der Pull-Methode gibt den Namen der Tabelle an, in der Fehler bei Push-Vorgängen gespeichert werden sollen. Die Fehlertabelle wird sofort erstellt, enthält aber zunächst keine Zeilen. ErrorTableName kann nur angegeben werden, wenn TRACKINGON oder TRACKINGON_INDEXES in der Pull-Methode angegeben ist.

Wenn ein Fehler auftritt, weil eine Zeile während der Push-Methode nicht angewendet werden kann, fügt SQL Server Compact 3.5 für jeden auftretenden Fehler einen Datensatz in die Tabelle ein. Zusammen mit allen Spalten aus der Basistabelle werden drei zusätzliche Spalten hinzugefügt, um die Ursache und den Zeitpunkt des Fehlers zu identifizieren. Die s_ErrorDate-Spalte gibt das Datum und die Uhrzeit des Fehlers an. Die s_OLEDBErrorNumber-Spalte gibt den HResult-Wert des Fehlers an, der beim Anwenden der Zeile auf den Server aufgetreten ist. Die s_OLEDBErrorString-Spalte ist eine Zeichenfolgenbeschreibung des Fehlers. Wenn die Push-Methode beendet ist und beim Versuch, Zeilen auf den Server anzuwenden, Fehler aufgetreten sind, wird eine Warnung (SSCE_WRN_RDAERRORROWSRETURNED, Wert 28800) an die Anwendung ausgegeben. Von der Anwendung kann dann die Fehlertabelle überprüft werden, um die Fehlerursache zu bestimmen.

Verwalten von Fehlertabellen

Fehlertabellen werden automatisch gelöscht, wenn die zugehörige nachverfolgte RDA-Tabelle gelöscht wird, selbst wenn noch Zeilen in der Fehlertabelle vorhanden sind. Der Entwickler muss Zeilen auflösen, die als konfliktverursachend betrachtet werden, da diese Zeilen nicht auf dem Server angewendet werden können.

Das Aktualisieren der Daten auf dem Gerät ist möglicherweise erforderlich, um den Fehler, der beim ursprünglichen Push von Daten zum Server aufgetreten ist, richtig aufzulösen. Sie sollten die Daten in der Fehlertabelle zwischenspeichern, sodass sie nicht verloren gehen, wenn Sie die nachverfolgte Tabelle löschen. Alternativ können Sie für die aktualisierten Daten einen Pull zu einer Tabelle ausführen, die einen anderen Namen als die ursprünglich nachverfolgte Tabelle hat.

Auflösen von Fehlern nach einem Datenpush

Der zusammen mit der fehlgeschlagenen Zeile in der Fehlertabelle gespeicherte Fehler beschreibt, warum die Zeile nicht auf dem Server eingefügt, aktualisiert oder gelöscht werden konnte. Abhängig davon, um was für einen Fehler es sich handelt, kann es sehr wichtig sein, den aktuellen Status der Daten auf dem Server zu kennen. Die Anwendung muss für die Behandlung dieser Situation konzipiert sein, da das Löschen der nachverfolgten Tabelle das Löschen der Fehlertabelle zur Folge hat.

Fehler und Transaktionen ohne Batch

Bei Transaktionen ohne Batch (BATCHINGOFF-Option bei Verwendung der Push-Methode) werden Konflikte auf Zeilenebene ermittelt. Die Konflikt verursachende Zeile wird an die Anwendung zurückgegeben und in einer angegebenen Fehlertabelle gespeichert. Wenn die Anwendung beispielsweise versucht, für eine ungültige Zeile einen Push zu SQL Server auszuführen, wird diese Zeile an die Anwendung zurückgegeben und zusammen mit einer Fehlermeldung, die den Konflikt angibt, in der Fehlertabelle gespeichert.

Wenn eine Zeile, die einen Konflikt verursacht, an die Fehlertabelle zurückgegeben wird, wird diese Zeile aus der ursprünglichen Tabelle entfernt. Da die Tabelle nicht in ihrem ursprünglichen Zustand belassen wird, ist es etwas schwieriger, den aufgetretenen Konflikt aufzulösen. Die Anwendung muss so konzipiert sein, dass der Benutzer die Konfliktdaten korrigieren kann. Dazu muss möglicherweise für die Tabelle erneut ein Pull vom Server ausgeführt werden, um den Konflikt richtig aufzulösen.

Durch das Löschen der Tabelle auf dem Gerät wird die Fehlertabelle gelöscht. Sie müssen die Zeilen in der Fehlertabelle entweder an einem temporären Speicherort zwischenspeichern oder für die Daten einen Pull vom Server in eine andere Tabelle ausführen. Da die Konflikt verursachenden Zeilen aus der Tabelle in der SQL Server Compact 3.5-Datenbank entfernt wurden, ist es wichtig, dass die Tabelle mit den richtigen Serverdaten erneut aktualisiert wird. Wenn die fehlgeschlagene Zeile ursprünglich aktualisiert wurde, muss eine erneute Aktualisierung derselben Zeile erfolgen, damit sie beim folgenden Push erfolgreich gesendet werden kann. Wenn die Zeile aktualisiert, die Zeile auf dem Server jedoch gelöscht wurde, muss die Zeile wieder der Tabelle hinzugefügt und ein erneuter Push ausgeführt werden, damit der Einfügevorgang erfolgreich ausgeführt werden kann.

Fehler und Batchtransaktionen

RDA bietet auch die Unterstützung für Push-Vorgänge mithilfe der Batchverarbeitung (BATCHINGON-Option bei Verwendung der Push-Methode). Diese erfordert das erfolgreiche Senden aller Zeilen, damit der vollständige Push verarbeitet werden kann. Wenn bei einer Zeile ein Fehler auftritt, schlägt die gesamte Pushtransaktion fehl, und es werden keine Daten aktualisiert. Die Konfliktzeilen werden in die Fehlertabelle kopiert. Dies ist die bevorzugte Methode, da so ein etwas einfacherer Mechanismus zur Auflösung des Konflikts angewendet werden kann. Anders als beim Push ohne Batch bleibt die ursprüngliche Microsoft Windows CE-basierte Datenbank intakt. Die Anwendung muss so konzipiert sein, dass der Benutzer die Konfliktdaten korrigieren und wieder in die ursprüngliche Windows CE-basierte Datenbank einfügen kann. Da die ursprüngliche Zeile intakt bleibt, ist es, je nach Art des Fehlers, möglicherweise nicht erforderlich, sofort einen erneuten Pull für die Serverdaten auszuführen, um die richtige Auflösung der Zeile zu bestimmen. Wenn der Fehler beispielsweise aufgrund einer Integritätsverletzung aufgetreten ist, kann die Zeile auf dem Gerät aktualisiert und die Push-Methode aufgerufen werden. Dies ermöglicht den Versuch, die Daten mithilfe eines Push-Vorgangs an den Server zu übertragen. Diese Option bietet außerdem eine Reinigungswartung, da die Fehlertabelle automatisch bereinigt wird, bevor eine Konfliktzeile kopiert wird. Lediglich die Konflikte aus dem letzten Push sind in der Tabelle vorhanden.