Mit Ausnahme von UltraLiteJ-Clients erzwingen alle MobiLink-Clients 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. Weitere Hinweise finden Sie unter:
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.
Der MobiLink-Client integriert die Änderungen aus dem Download in einer einzigen Transaktion. Um eine größere Flexibilität zu erzielen, findet die Prüfung der referenziellen Integrität am Ende dieser Transaktion statt. Da die Prüfung mit einer gewissen Verzögerung stattfindet, befindet sich die Datenbank zeitweise unter Umständen in einem Zustand, in dem die referenzielle Integrität nicht gewährleistet ist. Der Grund hierfür ist, dass Zeilen, die die referenzielle Integrität verletzen, vor dem Festschreiben des Downloads automatisch gelöscht werden.
Angenommen, 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.
Bei SQL Anywhere-Clients können Sie den Client-Ereignis-Hook sp_hook_dbmlsync_download_ri_violation verwenden, um auf die Verletzung der referenziellen Integrität zu reagieren. Dbmlsync schreibt außerdem einen Eintrag in sein Log.
Weitere Hinweise finden Sie unter:
| 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 |