Daten offline bearbeiten und synchronisieren
Die Beispiellösungen 04-EditRecords.mtd und 05-EditRecordsOnStart.mtd sind Beispiele dafür, wie Sie Daten offline bearbeiten können und nur online gehen müssen, um die Daten in einer Datenbank auf dem Server zu speichern.
Sie befinden sich im Ordner (Eigene) Dokumente: Altova\MobileTogetherDesigner8\MobileTogetherDesignerExamples\Tutorials\OfflineUsage. Öffnen Sie die Dateien in MobileTogether Designer und starten Sie Simulationen (F5), um zu sehen, wie die Lösungen funktionieren.
In beiden Lösungen werden Daten in einer SQLite-Datenbank (AddressesIndexed.sqlite) auf dem Server gespeichert. Die Lösung 04-EditRecords.mtd unterscheidet sich nur in einem Punkt von 05-EditRecordsOnStart.mtd: Datensätze aus der SQLite-Datenbank werden auf dem Startbildschirm der ersten Lösung nicht, auf dem der zweiten Lösung jedoch schon angezeigt.
Beschreibung der Beispiellösungen
In der Beispiellösung 04-EditRecords.mtd (Design in der Abbildung unten) werden die Datenbankdaten in einer Tabelle angezeigt und können vom Benutzer bearbeitet werden. Felder der Tabelle sind mit der Seitenquelle \$PERSISTENT verknüpft. Das bedeutet, dass (i) in der Tabelle der Inhalt von \$PERSISTENT angezeigt wird und (ii) dass Ihre Bearbeitungen an der Tabelle in \$PERSISTENT gespeichert werden.
Beim Start der Lösung 04-EditRecords.mtd ist die Tabelle leer (siehe Abbildung unten), da die Tabelle als Seitenquelle \$PERSISTENT hat und \$PERSISTENT leer ist. Beachten Sie, dass auch die Seitenquelle \$DB1 leer ist, da Sie auf "Daten laden = Nicht automatisch gesetzt wurde. Klicken Sie in Fenster "Seitenquellen" mit der rechten Maustaste auf \$DB1, um den Wert ihrer Einstellung Daten laden zu sehen.
In der Lösung können die folgenden Datenbearbeitungen vorgenommen werden:
•Es kann ein neuer Datensatz (Zeile) zur Tabelle hinzugefügt und die Felder des Datensatzes können bearbeitet werden. Um eine neue Zeile hinzuzufügen, klicken Sie auf das Plus-Symbol rechts von der letzten Zeile (siehe Abbildungen oben und unten). Nachdem Sie eine neue Zeile hinzugefügt haben, werden die Daten der Zeile in \$PERSISTENT gespeichert (siehe Abbildung unten).
•In der Lösung kann eine Zeile durch Klicken auf das Minus-Symbol der Zeile gelöscht werden (siehe Abbildung oben).
•Durch Klick auf Save to database können die Daten in \$PERSISTENT auf dem Server gespeichert werden. Eine Erläuterung dazu finden Sie im Abschnitt Speichern bearbeiteter Daten über Primärschlüssel und Originalzeilengruppen unten.
•Bei Klick auf Aktualisieren (in der Abbildung unten rot umrandet) werden alle Datenzeilen vom Server in \$DB1 heruntergeladen und von dort in \$PERSISTENT kopiert (siehe die auf dem Register des Ereignisses BeiSeitenaktualisierung definierten Aktionen). Alle vor der Aktualisierung vorhandenen Daten werden aus \$PERSISTENT gelöscht. Da in der Tabelle die Zeilen aus \$PERSISTENT angezeigt werden, werden nun in der Tabelle alle Server-Datensätze angezeigt. Beachten Sie, dass die Server-Zugriffseinstellung für \$DB1 auf Bei Bedarf gesetzt wurde. Damit wird sichergestellt, dass der Server nur kontaktiert wird, wenn an den Server ein Request wie der zum Neuladen von Datenbankdaten gesendet wird. Dadurch können Benutzer so lange offline arbeiten, bis sie Daten auf dem Server aktualisieren müssen.
Schlüsseleinstellungen
In der folgenden Tabelle sehen Sie zum Vergleich die Schlüsseleinstellungen der Lösung (04-EditRecords.mtd).
04-EditRecords.mtd | Auswirkung |
Daten (von \$DB1) laden = Nicht automatisch | Die Datenbankdaten des Servers werden beim Start der Lösung nicht angezeigt. |
Server-Zugriff (von \$DB1) = Bei Bedarf | Der Client verbindet sich nur mit dem Server, wenn dies aufgrund einer Aktion erforderlich ist. |
Mit BeiSeitenaktualisierung werden Datenbankdaten vom Server neu geladen, Nodes von \$PERSISTENT gelöscht und die neuen Nodes von \$DB1 an \$PERSISTENT angehängt. | Bei Aktualisierung der Seite wird \$DB1 neu mit Daten vom Server befüllt und diese Daten werden in \$PERSISTENT kopiert. Die Tabelle enthält dadurch die neuesten Daten vom Server. |
Laden aller Daten für die Bearbeitung beim Start der Lösung
Beim Start der Lösung 04-EditRecords.mtd ist die Tabelle leer, da \$PERSISTENT leer ist. Für die Anzeige aller Datenbankdaten des Servers in der Tabelle könnten wir die folgende in 05-EditRecordsOnStart.mtd verwendete Methode verwenden. Um zu sehen, wie dies definiert wurde, öffnen Sie 05-EditRecordsOnStart.mtd und überprüfen Sie, was für das BeimLadenDerSeite-Ereignis der Lösungsseite definiert wurde.
1.Da die gewünschten Aktionen beim Start der Lösung aufgerufen werden müssen, erstellen wir sie für das BeimLadenDerSeite-Ereignis der Startseite der Lösung.
2.\$DB1 über die Aktion Neu laden neu laden. Dadurch werden (beim Start der Lösung) alle Datenbankdaten vom Server in \$DB1 heruntergeladen.
3.Alle Datensätze von \$PERSISTENT über die Aktion Node(s) löschen löschen.
4.Alle Datensatz-Nodes aus \$DB1 mit Hilfe der Aktion Node(s) aktualisieren in \$PERSISTENT kopieren. Sobald die Daten an die \$PERSISTENT-Struktur angehängt wurden, werden sie automatisch in der Tabelle angezeigt, da die Steuerelemente in den Zellen der Tabelle Seitenquellen-Links zu den Nodes der Seitenquelle \$PERSISTENT haben.
Speichern bearbeiteter Daten über Primärschlüssel und Originalzeilengrupen
Sowohl in 04-EditRecords.mtd als auch in 05-EditRecordsOnStart.mtd wurde die Einstellung zum Erstellen eines OriginalRowSet-Node auf "true" gesetzt. Diese Einstellung wird über einen Ein/Aus-Befehl im Kontextmenü der Seitenquelle aktiviert. In beiden Beispielen wird die Seitenquelle \$DB1 bei jeder Aktualisierung der Seite (über die Schaltfläche Aktualisieren) neu vom Server geladen und es werden zwei wichtige Schritte durchgeführt: (i) In \$DB1 wird ein OriginalRowSet-Node erstellt, der eine exakte Kopie des RowSet-Node der Struktur (d.h. aller Zeilen der Server-Datenbank) enthält und (ii) die Nodes RowSet und OriginalRowSet werden aus \$DB1 in die \$PERSISTENT-Struktur kopiert. Auf diese Art wissen wir, welche Zeilen ursprünglich vor der Bearbeitung in der Tabelle vorhanden waren: Bearbeitete Zeilen befinden sich in RowSet, während sich Originalzeilen in OriginalRowSet befinden.
Wenn die Tabelle nun bearbeitet wird, d.h. wenn neue Zeile hinzugefügt oder Zeilen gelöscht werden, so unterscheidet sich in \$PERSISTENT die Anzahl der Zeilen in in RowSet von der in OriginalRowSet. Jede Zeile wird durch ein Feld für den eindeutigen Primärschlüssel namens ID gekennzeichnet, welcher nicht NULL sein darf und welcher automatisch bei Hinzufügen einer Zeile auf eine automatisch inkrementierte Ganzzahl gesetzt wird.
Wenn die Daten in der Server-Datenbank gespeichert werden, geschieht Folgendes:
1.\$DB1 wird mit Hilfe der Aktion Neu laden neu geladen.
2.Diejenigen Zeilen aus \$DB1/RowSet, die dieselbe ID wie die Zeilen in \$PERSISTENT/OriginalRowset haben, werden gelöscht. Damit wird sichergestellt, dass alle Originalzeilen (vor der Bearbeitung) aus \$DB1/RowSet gelöscht werden.
3.Die Zeilen von \$PERSISTENT/Rowset werden mit Hilfe der Aktion Node(s) anhängen in \$DB1/RowSet. kopiert. Dies sind die neuen, die bearbeiteten und die nicht bearbeiteten Zeilen in \$PERSISTENT/Rowset, die auf dem Server gespeichert werden sollen. Zeilen, die aus der Tabelle gelöscht wurden, befinden sich nicht in diesem RowSet und werden daher nicht in \$DB1 kopiert. \$DB1 enthält daher nur die Zeilen, die wieder auf dem Server gespeichert werden sollen.
4.Die Daten aus \$DB1 werden mit Hilfe einer Speichern-Aktion in der SQLite-Datenbank auf dem Server gespeichert, wobei nur Änderungen gespeichert werden.