Dieses Polling-Ereignis akzeptiert ein SQL-Skript. Es wird ausgelöst, um Bereinigungsvorgänge auszuführen, wenn erkannt wird, dass Push-Anforderungen gelöscht werden müssen. Es akzeptiert die Anforderungs-ID als Parameter und wird für jede Anforderungs-ID ausgeführt. Das request_cursor-Ereignis muss eine Spalte für die Anforderungs-ID enthalten, um das request_delete-Ereignis zu verwenden. Sie können die Anforderungs-ID mit einem benannten Parameter referenzieren oder einem Fragezeichen (? ). Dieses Ereignis ist optional, wenn Sie bereits einem anderen Prozess oder Ereignis, wie z.B. dem end_poll-Ereignis, Bereinigungsvorgänge zugewiesen haben.
Der Notifier kann mit der DELETE-Anweisung folgende Formen von Push-Anforderungen löschen:
Implizit gelöscht Diese Push-Anforderungen sind früher schon vorgekommen, doch sie kommen nicht in der aktuellen Menge von Anforderungen vor, die aus request_cursor bezogen wurden.
Bestätigt Diese Push-Anforderungen sind als zugestellt bestätigt.
Abgelaufen Diese Push-Anforderungen sind basierend auf ihren Sendewiederholungs-Attributen und der aktuellen Uhrzeit abgelaufen. Anforderungen ohne Attribute zur Sendewiederholung werden als abgelaufen betrachtet, selbst wenn sie in der nachfolgenden Anforderung enthalten sind.
Sie können mit dem request_delete-Ereignis verhindern, dass abgelaufene oder implizit gelöschte Anforderungen gelöscht werden. Beispiel: Das Beispiel CarDealer im Verzeichnis %SQLANYSAMP12%\MobiLink\SIS_CarDealer verwendet das request_delete-Ereignis, um das Statusfeld der PushRequest-Tabelle auf 'processed' (verarbeitet) zu setzen.
UPDATE PushRequest SET status='processed' WHERE req_id = ? |
Das begin_poll-Ereignis im Beispiel verwendet die Zeit der letzten Synchronisation, um zu prüfen, ob entfernte Geräte auf dem aktuellen Stand sind, bevor verarbeitete Push-Anforderungen gelöscht werden.
![]() |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |