BD Commencer la transaction
Lorsque l'événement est déclenché, l'action BD Commencer la transaction entame une transaction avec la source de données sélectionnée dans la liste de choix Connexion. Cette liste de choix recense toutes les sources de données du projet et propose également l'option de configurer une connexion de base de données supplémentaire spécifiquement pour une utilisation avec l'action BD Commencer la transaction.
L'option Verrouillage de transaction spécifie le niveau de protection et vous permet de vous assurer que les données ne sont pas corrompues pendant les actions d'écriture. Les options suivantes sont disponibles :
•Réglages par défaut de la base de données : collecte les paramètres par défaut liés à la BD sur la BD, le serveur et le client.
•Empêche l'écriture sur les tables touchées : Il n'y aura pas d'écriture sur la BD si une autre opération d'écriture a lieu depuis une autre connexion au même moment. La transaction d'écriture sera repoussée jusqu'à ce que l'autre transaction d'écriture soit achevée, sinon un message d'erreur s'affichera.
•Empêche l'écriture sur les tables touchées : Il n'y aura pas d'écriture sur la BD si une autre opération d'écriture a lieu depuis une autre connexion au même moment. La transaction sera repoussée jusqu'à ce que l'autre transaction soit achevée, sinon un message d'erreur s'affichera.
•Exclusif : il s’agit d’une fonction SQLite. Lorsque la transaction EXCLUSIVE est active, d’autres connexions ne sont pas à même de lire ou écrire dans la BD et obtiennent une erreur ayant pour effet que la BD est verrouillée.
Si vous vous connectez à une base de données SQLite, une propriété Délai d’expiration (en secondes) devient disponible. Cela vous permet de spécifier une période d’attente pour appliquer une verrouillage d’écriture. Si aucune période de délai d’expiration n’est spécifiée, SQLite abandonnera immédiatement si un verrouillage d’écriture n’est pas appliqué au début de la transaction.
Traitement d'erreur
L'option sur erreur vous permet de définir les actions à exécuter en cas d'erreur. Puisque le traitement de l'erreur peut être défini précisément pour cette action, les erreurs sur de telles actions (qui permettent la gestion des erreurs) sont traitées en tant qu'avertissements - et pas en tant qu'erreurs. L'avantage est que vous ne devez pas vérifier les erreurs sur les actions pour lesquelles le traitement d'erreur a déjà été défini. Les options de gestion des erreurs suivantes sont disponibles :
•Abandonner le script : en cas d'erreur, toutes les actions suivantes de l'événement déclenché sont terminées. Il s'agit là de l'action par défaut si une erreur se produit. Si vous souhaitez continuer malgré une erreur, sélectionnez l'option Continuer ou Throw.
•Continuer : les actions ne sont pas terminées. Au lieu, vous pouvez sélectionner ce que vous souhaitez faire dans les cas variés : en cas d'absence d'erreur (Sur succès), ou en cas d'erreur (Sur erreur). Par exemple, si vous souhaitez afficher une fenêtre de messages indiquant si un chargement de page a été effectué avec succès ou pas.
•Throw: si une erreur est détectée, cette option lance une exception qui sera stockée dans la variable de l'action Try/Catch. La partie Catch de l'action Try/Catch est utilisée pour spécifier quelle action doit être effectuée en cas d'erreur. Si aucune erreur ne se produit, l'action suivante sera traitée. Voir la section action Try/Catch pour plus de détails.
À propos des transactions BD Une transaction est automatiquement créée puis fermée pour chaque accès BD nécessitant une transaction. Dans certains cas, cela peut ne pas être souhaitable, par exemple pour certaines configurations. Concrètement par exemple, si vous avez deux sources de page BD que vous souhaitez mettre à jour ensemble : si les deux tables sont enregistrées avec succès, la transaction est validée, mais dans le cas d'un échec de l'enregistrement, elle sera annulée. Pour parer à ce type de situation, vous pouvez créer des transactions sur la base d'une connexion.
Si vous commencez une transaction, toutes les opérations de BD appartenant à la même connexion BD utiliseront cette transaction.
La validation d'une transaction rend les changements visibles à l'extérieur de votre transaction. Les changements peuvent être annulés. Dans ce cas, même si vous avez effectué un enregistrement sur votre source de page, les changements ne seront pas visibles après une annulation ! Veuillez noter que toute transaction qui n'est pas fermée (validée ou annulée) une fois que la fin de l'arborescence d'action a été atteinte sera annulée automatiquement ! Un avertissement sera affiché dans la fenêtre Messages.
Il est important de retenir que, alors que le comportement décrit ci-dessus concerne les actions de transaction explicites, il s'applique également à toutes les opérations de BD qui utilisent la même connexion que la transaction.
|
Fonctions d'extension de MobileTogether
MobileTogether fournit une série de fonctions d'extension XPath qui ont été créées spécifiquement pour l'utilisation dans les designs MobileTogether. Quelques fonctions peuvent être particulièrement utiles avec des actions spécifiques. Par exemple, mt-available -languages() renvoie les langues dans lesquelles la solution est disponible et pourrait, par exemple, être utilisée avec l'action Boîte de messages. Si une fonction est particulièrement pertinente pour cette action, elle se trouvera dans la liste ci-dessous. Pour une liste complète de ces fonctions d'extension et leurs descriptions, voir la page <Fonctions d'extension MobileTogether.
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()