- Présentation
- Principe
- Principe des transactions sur des fichiers HFSQL Client/Serveur et HFSQL Classic
- Gestion avancée
- Fichiers créés par une transaction
- Organisation des fichiers sur le serveur
- Identifiant du poste réalisant la transaction
- Erreurs spécifiques à la gestion des transactions en mode HFSQL Client/Serveur
Transactions en mode HFSQL Client/Serveur
 Disponible uniquement avec ce type de connexion
Pour conserver une compatibilité maximale entre les applications HFSQL Classic (monoposte ou réseau) et les applications HFSQL Client/Serveur, le mécanisme des transactions en mode HFSQL Client/Serveur est proche du fonctionnement en mode HFSQL Classic. Cette page d'aide présente uniquement les différences de fonctionnement. Principe des transactions sur des fichiers HFSQL Client/Serveur et HFSQL Classic Chaque opération d'écriture effectuée lors d'une transaction est mémorisée dans un fichier des transactions. A tout moment, il est possible d'annuler la transaction : toutes les opérations effectuées depuis le début de la transaction seront annulées. La transaction est automatiquement annulée : - lors d'une erreur fatale du programme (suivie d'une fermeture de l'application).
- lors de l'appel de la fonction FinProgramme.
- lors de l'arrêt du mode test depuis l'éditeur.
- lors d'une panne de courant ou d'un arrêt brusque de l'application.
- lors de la perte ou de la fermeture de la connexion par le client.
- lors du redémarrage du serveur. Attention : la transaction n'est pas annulée si la transaction porte sur un fichier avec mot de passe sécurisé. La transaction sera annulée à la prochaine ouverture du fichier de données.
Isolation des transactions
Le moteur HFSQL propose d'isoler les transactions : les modifications effectuées dans une transaction en cours sont isolées de celles faites dans les autres transactions conduites simultanément, jusqu'à ce qu'elle soit validée. Plusieurs modes d'isolation sont disponibles : - "READ UNCOMMITTED" : Lecture des données non validées (mode par défaut).
- "READ COMMITTED" : Lecture des données validées.
- "REPEATABLE READ" : Transactions photographiées
Fichiers créés par une transaction Lors de la mise en place des transactions, plusieurs types de fichiers HFSQL sont créés : - le journal des opérations en transaction : Fichier au format HFSQL contenant les différentes opérations réalisées sur les fichiers de l'application pris en compte par la transaction. Ce fichier est créé par la fonction HTransactionDébut (ou par la fonction HTransaction). Son nom est TRSOPERATION.TRS.
- le journal d'identification : Fichier contenant des informations uniques permettant d'identifier la transaction (nom de client, poste, ...). Ce fichier a pour nom TRSOperationInfoClient.TRS.
- le journal des valeurs : Fichier associé à chaque fichier de données pris en compte par la transaction. Ce fichier s'appelle <NomFichier>.TRX. Ce fichier contient pour chaque opération réalisée dans la transaction :
- soit le contenu de l'enregistrement avant l'opération (lors d'une suppression par exemple).
- soit le contenu de l'enregistrement après l'opération (lors d'un ajout par exemple).
Organisation des fichiers sur le serveur | |  | 1. Répertoire __TRS
Ce répertoire contient :- Le journal des opérations en transaction.
- Le journal d'identification
- Pour chaque fichier de données en transaction de chaque base de données, le fichier des valeurs correspondant. L'arborescence utilisée correspond à l'arborescence des fichiers de données associés à la base.
Par exemple, si le fichier Commande de DonneesApplicationA est mis en transaction, le sous-répertoire __TRS\DonneesApplicationA contiendra le fichier Commande.TRX.
Autre exemple : si le fichier Client de DonneesApplicationB est mis en transaction, le sous-répertoire __TRS\DonneesApplicationB\Client contiendra le fichier Client.TRX.
2. Répertoire de la base de données DonneesApplicationA
3. Répertoire de la base de données DonneesApplicationB |
Identifiant du poste réalisant la transaction L'identification du poste réalisant la transaction se fait de la même façon en HFSQL Classic et en HFSQL Client/Serveur : par défaut, le poste est identifié par un numéro unique interne et par le nom du poste (nom défini sous Windows). Pour identifier simplement le poste effectuant les opérations en transactions, la fonction HPoste permet de définir un identifiant spécifique au poste. Cet identifiant remplace le nom du poste. Cet identifiant est enregistré dans le journal des opérations en transaction et peut être consulté avec le centre de contrôle HFSQL. Le client est identifié par : - la fonction HPoste (identique à HFSQL Classic).
- Nom de l'ordinateur et son adresse IP.
- Nom de l'application c'est-à-dire NomExécutable (NomProjet).
Ces informations peuvent être récupérées en cas d'interruption de la transaction par la fonction HTransactionInterrompue. Erreurs spécifiques à la gestion des transactions en mode HFSQL Client/Serveur 74020 : Le mot de passe du fichier de Transaction ne correspond pas au mot de passe du fichier d'origine Le fichier de données (en mode HFSQL Client/Serveur) et le fichier de transaction n'utilisent pas le même mot de passe. 70032 : Problème de mode d'isolation
Cette erreur peut survenir dans les cas suivants : - Vous tentez d'utiliser la fonction HTransactionIsolation sur des fichiers de données qui ne sont pas au format Client/Serveur.
- Vous tentez d'utiliser un mode d'isolation alors que la transaction n'est pas effectuée sur une connexion.
- Vous tentez d'utiliser la fonction HTransactionIsolation alors que la transaction a déjà été débutée avec la fonction HTransactionDébut (ou la fonction HTransaction).
Liste des exemples associés :
|
Exemples didactiques (WINDEV) : WD Transaction
[ + ] Ce programme réalisé avec WINDEV est basé sur une analyse simplifiée du type COMMANDE, LIGNECOMMANDE, STOCK. Il illustre le fonctionnement des transactions lors du passage d'une commande.
|
Documentation également disponible pour…
|
|
|
|