Mit Ausnahme von UltraLiteJ-Clients erzwingen alle MobiLink-Clients für BlackBerry oder J2SE referenzielle Integrität, wenn sie den Download in die entfernte Datenbank integrieren.
Der MobiLink-Client löscht standardmäßig automatisch alle Zeilen, die die referenzielle Integrität verletzen, damit die Downloadtransaktion nicht fehlschlägt.
Diese Funktion bietet folgende Vorteile:
Schutz vor Fehlern in den Synchronisationsskripten. Aufgrund der Flexibilität der Skripten ist es möglich, dass ungewollt ein Download von Zeilen erfolgt, die die Integrität der Datenbank verletzen würden. Der MobiLink-Client bewahrt automatisch die referenzielle Integrität, ohne dass ein Eingriff von außen erforderlich wird.
Sie können diesen Mechanismus zur referenziellen Integrität einsetzen, um Daten aus einer entfernten Datenbank effizient zu löschen. Wenn Sie einen Löschvorgang für einen übergeordneten Datensatz senden, entfernt der MobiLink-Client automatisch alle untergeordneten Datensätze. Damit wird das von MobiLink an die entfernte Datenbank zu übertragende Datenaufkommen erheblich reduziert.
MobiLink-Clients geben wie folgt Benachrichtigungen aus, wenn sie explizit Zeilen löschen müssen, um die referenzielle Integrität zu erhalten:
Für SQL Server Anywhere-Clients schreibt dbmlsync einen Eintrag in das Log. Außerdem können Sie dbmlsync-Ereignis-Hooks verwenden. Siehe:
Für UltraLite-Clients wird die Warnung SQLE_ROW_DELETED_TO_MAINTAIN_REFERENTIAL_INTEGRITY ausgegeben. Diese Warnung verwendet den Tabellennamen als Parameter. Um die referenzielle Integrität aufrechtzuerhalten, wird die Warnung für jede gelöschte Zeile ausgegeben. Ihre Anwendung kann die Warnung ignorieren, wenn mit der Synchronisation fortgefahren werden soll. Falls Sie die Warnmeldungen explizit behandeln wollen, können Sie sie mit der Fehler-Callback-Funktion abfangen und beispielsweise die Anzahl der gelöschten Zeilen ermitteln.
Wenn die Synchronisation bei Ausgabe der Warnung abgebrochen werden soll, müssen Sie eine Synchronisationsbeobachtungsfunktion implementieren und dann der Beobachtungsfunktion (z.B. durch eine globale Variable) von der Fehler-Callback-Funktion aus ein Signal senden. In diesem Fall schlägt die Synchronisation beim nächsten Aufruf der Beobachtungsfunktion fehl.
Referenzielle Integrität wird am Ende der Transaktion geprüft BeispielAngenommen, eine UltraLite-Verkaufsanwendung enthält die folgenden beiden Tabellen: Eine Tabelle enthält Aufträge. Eine andere Tabelle enthält Artikel, die in den einzelnen Aufträgen verkauft wurden. Sie haben folgende Beziehung:
Wenn Sie download_delete_cursor für die Tabelle sales_order verwenden, um einen Auftrag zu löschen, dann löscht der standardmäßige Mechanismus der referenziellen Integrität automatisch alle Zeilen in sales_order_items, die auf die gelöschten Bestellungen verweisen, um die referenzielle Integrität aufrechtzuerhalten.
Dieser Mechanismus bietet folgende Vorteile:
Sie benötigen kein sales_order_items-Skript, da die betreffenden Zeilen dieser Tabelle automatisch gelöscht werden.
Die Effizienz der Synchronisation wird verbessert. Sie brauchen den Download der aus der Tabelle sales_order_items zu löschenden Zeilen nicht vorzunehmen. Wenn die einzelnen Bestellungen mehrere Artikel enthalten, wird dadurch die Performance gesteigert, da der Download nun kleiner ist. Diese Technik ist dann besonders hilfreich, wenn relativ langsame Verbindungen verwendet werden.
Das Standardverhalten ändern |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |