DB Begin-Transaktion
Bei Auslösung des Ereignisses beginnt die DB Begin-Transaktion eine Transaktion mit der in der Auswahlliste Verbindung ausgewählten Datenquelle. In dieser Auswahlliste werden alle Datenquellen des Projekts aufgelistet. Sie haben hier auch die Möglichkeit, eine zusätzliche Datenbankverbindung speziell für die Aktion "DB Begin-Transaktion" zu definieren.
Mit der Option Transaktionssperre setzen definieren Sie den Grad der Sperre und stellen damit sicher, dass die Daten bei Schreib-Aktionen nicht beschädigt sind. Es stehen die folgenden Optionen zur Verfügung:
•Datenbankstandardeinstellung: Sammelt die Standarddatenbankeinstellungen von Datenbank, Server und Client.
•Schreiben betroffener Tabellen verhindern: Es wird nicht in die Datenbank geschrieben, falls gerade von einer anderen Verbindung aus Daten in die Datenbank geschrieben werden. Die Schreib-Transaktion wird erst dann ausgeführt, wenn die andere Schreib-Transaktion abgeschlossen ist. Andernfalls wird eine Fehlermeldung angezeigt.
•Schreiben und Lesen betroffener Tabellen verhindern: Daten werden weder in die Datenbank geschrieben noch daraus gelesen, falls gerade von einer anderen Verbindung aus Daten in die Datenbank geschrieben werden. Die Transaktion wird erst dann ausgeführt, wenn die andere Transaktion abgeschlossen ist oder es wird eine Fehlermeldung angezeigt.
•Exklusiv: Dies ist eine SQLite-Funktionalität. Wenn die EXKLUSIVE Transaktion aktiv ist, kann die Datenbank nicht aus anderen Verbindungen gelesen oder beschrieben werden. Für die Verbindung wird ein Fehler mit der Meldung, dass die Datenbank gesperrt ist, angezeigt.
Bei Verbindung zu einer SQLite-Datenbank steht die Eigenschaft Timeout (in Sekunden) zur Verfügung. Dadurch können Sie definieren, wie lange gewartet werden soll, bevor eine Schreibsperre angewendet wird. Wenn kein Timeout definiert wird, bricht SQLite die Transaktion sofort ab, falls bei Beginn der Transaktion keine Schreibsperre angewendet wurde.
Fehlerverarbeitung
Mit der Option Bei Fehler können Sie definieren, wie bei Auftreten eines Fehlers vorgegangen wird. Da die Fehlerbehandlung für diese Aktion genau definiert werden kann, werden Fehler in solchen Aktionen (für die eine Fehlerbehandlung vorgesehen ist) als Warnungen und nicht Fehler behandelt. Der Vorteil davon ist, dass Sie Fehler bei Aktionen, für die bereits eine Fehlerbehandlung definiert wurde, nicht überprüfen müssen. Die folgenden Fehlerbehandlungsoptionen stehen zur Verfügung:
•Skript abbrechen: Sobald ein Fehler auftritt, werden alle nach diesem Ereignis durchzuführenden Aktionen beendet. Dies ist das Standardverhalten bei Auftreten eines Fehlers. Wenn Sie möchten, dass auch bei einem Fehler fortgefahren werden soll, wählen Sie entweder die Option Weiter oder Throw aus.
•Weiter: Die Aktionen werden nicht beendet. Sie können stattdessen auswählen, was in jedem der beiden Fälle (kein Fehler (Bei Erfolg) oder Auftreten eines Fehlers (Bei Fehler)) geschehen soll. So kann z.B. ein Meldungsfeld definiert werden, das den Benutzer darüber informiert, ob eine Seite erfolgreich geladen werden konnte oder nicht.
•Throw: Wenn ein Fehler aufgetreten ist, wird mit dieser Option eine Ausnahme ausgelöst, die in der Variablen der Try/Catch-Aktion gespeichert wird. Mit dem Catch-Teil der Try/Catch-Aktion wird definiert, welche Aktion bei Auftreten eines Fehlers durchgeführt werden soll. Wenn kein Fehler auftritt, wird die nächste Aktion verarbeitet. Nähere Informationen dazu finden Sie im Abschnitt zur Aktion "Try/Catch Ausnahme".
Informationen zu DB-Transaktionen Für jeden DB-Aufruf, für den eine Transaktion erforderlich ist, wird automatisch eine erstellt und anschließend geschlossen. Dies ist in einigen Konfigurationen eventuell nicht wünschenswert. Angenommen, Sie haben zwei DB-Seitenquellen, die einzeln zusammen aktualisiert werden sollen: Wenn beide Tabellen erfolgreich gespeichert wurden, so wird die Transaktion in die DB übernommen, andernfalls erfolgt ein Rollback. Zu diesem Zweck können Transaktionen auf einer Verbindungsbasis erstellt werden.
Wenn Sie eine Transaktion beginnen, verwenden alle DB-Operationen, die zur selben DB-Verbindung gehören, diese Transaktion.
Bei Verwendung einer Commit-Transaktion werden die Änderungen außerhalb Ihrer Transaktionsumgebung sichtbar. Änderungen können mit Rollback rückgängig gemacht werden. In diesem Fall sind die Änderungen, selbst wenn Sie Ihre Seitenquelle gespeichert haben, nach Durchführung eines Rollback nicht sichtbar! Beachten Sie, dass jede nicht abgeschlossene Transaktion (jede Transaktion, die nicht mit Commit übernommen oder mit Rollback rückgängig gemacht wurde) bei Erreichen des Endes der Aktionsstruktur automatisch mit Rollback rückgängig gemacht wird! Im Meldungsfenster wird dann eine entsprechende Warnung angezeigt.
Beachten Sie bitte, dass sich dieses Verhalten zwar auf explizite Transaktionsaktionen bezieht, aber auch für alle DB-Operationen gilt, die dieselbe Verbindung wie die Transaktion verwenden.
|
MobileTogether-Erweiterungsfunktionen
MobileTogether enthält eine Reihe von XPath-Erweiterungsfunktionen, die speziell für die Verwendung in MobileTogether-Designs erstellt wurden. Einige davon können bei bestimmten Aktionen sehr nützlich sein. So erhalten Sie etwa mit mt-available-languages() die Sprachen, in denen die Lösung zur Verfügung steht. Diese Funktion könnte z.B. mit der Aktion Meldungsfeld verwendet werden. Wenn eine Funktion für diese Aktion besonders relevant ist, ist sie unten aufgelistet. Eine vollständige Liste aller Erweiterungsfunktionen und mit Beschreibungen finden Sie im Kapitel MobileTogether-Erweiterungsfunktionen.
mt-available-db-connection-names()
mt-db-any-changed-fields()
mt-db-any-changed-rows()
mt-db-deleted-original-fields()
mt-db-deleted-original-rows()
mt-db-file-path()
mt-db-modified-fields()
mt-db-modified-rows()
mt-db-new-fields()
mt-db-new-rows()
mt-db-original row()
mt-external-error-code()
mt-external-error-text()