• entre une base de données HFSQL Classic et une base de données Oracle.
• entre des bases de données HFSQL Classic ou HFSQL Client/Serveur.
• etc.

• Fichier .rpm : fichier permettant de décrire une base maître et les bases qui lui sont abonnées. Contient le nom du fichier ".syn" pour chaque abonné. Ce fichier est un fichier texte. Il est créé et stocké sur le poste qui servira à se connecter à la base maître.
• Fichier .rpl : fichier décrivant une base abonnée. Pour chaque base abonnée, un fichier "rpl" est créé. Ce fichier est présent sur le poste abonné. Contient le nom du fichier ".syn" de l'abonné. Ce fichier est un fichier texte. Il est créé sur le poste maître puis transféré sur le poste abonné.
• Fichier .rpa : fichier journal contenant les informations de réplication. Ce fichier est échangé entre la base de données maître et la base de données abonnée. Ce fichier est créé par la fonction HCréeRéplicaTransportable et il est lu et détruit par la fonction HSynchroniseRéplica. Le contenu est incrémentiel : s'il y a deux HCrééRéplicaTransportable dans le même sens effectués à la suite alors le second fichier contiendra l'équivalent du premier en ajoutant les modifications récentes. Si un ".rpa" est "perdu", il suffit de le refaire : il contiendra toutes les modifications. Si plusieurs fichiers "rpa" sont présents sur l'abonné, il suffit d'exécuter le dernier. Ce fichier est dans un format binaire.
• Fichier .syn : fichier contenant les informations sur la situation de la base distant. Ce fichier permet d'optimiser la taille des fichiers de synchronisation. Ce fichier est présent sur le poste maître et sur chaque poste abonné. Ce fichier est dans un format binaire.

Fonctionnement de la réplication

Structure de la base de données

Etape 1 : Mise en place sur le site maître

1. Pour activer la réplication universelle, il suffit d'utiliser la fonction HGèreRéplication avec la constante rplRéplicationUniverselle.
   
   HGèreRéplication(rplRéplicationUniverselle)
   
   
   Cette fonction permet de désactiver le mode de réplication standard (s'il était actif) et d'activer la réplication universelle.
2. Création du répertoire d'accueil des données (optionnel)
   Vous pouvez créer un répertoire qui recevra les fichiers de la base de données. Ce répertoire sera partagé sur le serveur du site maître pour que les utilisateurs puissent accéder aux données.
   
   // Création du répertoire des données
   fRepCrée(gsRépertoireMaître)
   // Connexion à cet emplacement
   HOuvreConnexion(ConnexionMaître)
   HChangeConnexion(CLIENT, ConnexionMaître)
   
3. Création des fichiers de données de l'application (optionnel)
   Si les fichiers de données n'existent pas, vous pouvez créer les fichiers de données vides (fonction HCréation). Ces données seront manipulées par les utilisateurs du site maître.
4. Création du réplica maître
   Pour déclarer la base maître, il suffit d'utiliser la fonction HCréeRéplicaMaître.
   
   HCréeRéplicaMaître(gsRépertoireMaître)
   
   
   Cette ligne de code crée le fichier "RéplicaMaître.rpm" sur le disque. Il ne reste plus qu'à inscrire les abonnés dans ce fichier.

Etape 2 : Préparation des données du site abonné

1. Création d'un répertoire d'accueil des données (optionnel)
   Vous pouvez créer un répertoire qui recevra les fichiers de la base de données.
2. Création du réplica abonné
   Pour créer un nouvel abonné, utilisez la fonction HCréeRéplicaAbonné. Cette fonction crée un abonné (fichier "rpl") avec le nom fourni. Cette fonction renvoie également un numéro d'abonné.
   Dès sa création, l'abonné est prêt à recevoir les données du réplica maître qui a permis de l'initialiser. Cette première synchronisation permet d'obtenir un contenu de l'abonné identique à celui du maître.
   
   // Création du réplica abonné
   HCréeRéplicaAbonné(gsRepertoireMaître, gsRepertoireAbonne, ...
   "Abonné1", 0, "Client" + TAB + "IDDATEHEURE")
   
   
   Dans cet exemple, la rubrique "IDDATEHEURE" correspond à une rubrique de type "DateHeure" dont la base de données doit disposer (cas d'une base non HFSQL Classic ou Client/Serveur). Cette rubrique devra être mise à jour par l'application lors de la modification ou lors de l'ajout d'un enregistrement. Si les bases de données utilisent différents fuseaux horaires, il est conseillé d'utiliser un format universel (date et heure GMT par exemple).
   Cette rubrique n'est pas nécessaire dans le cas d'une base de données HFSQL Classic ou Client/Serveur.
   Remarque : Un paramètre de la fonction HCréeRéplicaAbonné permet d'indiquer si la modification automatique des données doit être prise en compte. Pour plus de détails, consultez Les remarques.

• Code du trigger :
  

  ResultatTrigger est un booléen
  ResultatTrigger = HDécritTrigger("*", "HAJOUTE,HMODIFIE,HSUPPRIME,HRAYE,HECRIT", ...
  		"AjoutDateHeure",hTriggerAvant)
  SI ResultatTrigger = Faux ALORS Erreur(HErreurInfo())

• Procédure appelée par le trigger :
  

  PROCÉDURE AjoutDateHeure()
  TestReplic.Rub_DateHeure = DateSys() + HeureSys()

Etape 3 : Mise en place sur le site abonné

1. Lorsque les données sont "préparées" pour le site abonné (fichiers ".rpl", ".syn"), il suffit d'activer le mécanisme de réplication sur le site abonné (fonction HGèreRéplication).
   
   HGèreRéplication(rplRéplicationUniverselle)
   
2. Le site abonné doit créer sa base de données vierge (fonction HCréation) avant la première synchronisation :
   
   HCréation(CLIENT)
   
   
   Cette base de données sera initialisée lors de la première synchronisation.

Etape 4 : Synchronisation initiale des sites maître et abonnés

1. Création d'un réplica transportable :
   A partir de la base maître, un réplica transportable va être créé. il va contenir les données de la base depuis laquelle le réplica maître a été créé. Cette opération est réalisée grâce à la fonction HCréeRéplicaTransportable. La fonction HCréeRéplicaTransportable crée un fichier journal (fichier ".rpa").
   
   HCréeRéplicaTransportable(sReplicaMaître, "Maitre","")
   
2. Intégration du réplica transportable dans la base abonnée :
   Les données de la base maître sont importées dans la base abonnée grâce à la fonction HSynchroniseRéplica.
   

   sReplicaTransportable = gsRépertoireMaître + RPL.Fichier
   HSynchroniseRéplica(sReplicaTransportable, ...
   	gsRepertoireAbonne + "Replica_Abonne1.rpl", rplVersAbonné)
   fSupprime(sReplicaTransportable)

3. La création de l'abonné est terminée. Il est alors possible de transporter les fichiers de l'abonné sur le site d'exploitation de l'abonné. Cette opération peut être effectuée par un moyen de copie quelconque, le tout étant de créer une base vide, et d'effectuer une première réplication sur le site.

• Dès qu'un réplica abonné a été initialisé, il ne faut plus remplacer/restaurer l'un des fichiers maître (car ils contiennent des informations relatives aux plages d'identifiants des réplicas abonnés).
• Tous les fichiers d'une base de données ne doivent pas obligatoirement être répliqués. Répliquez uniquement les fichiers de données nécessaires.

Etape 5 : Synchronisations quotidiennes

1. Générer un réplica transportable (fonction HCréeRéplicaTransportable).
2. Transmettre le réplica transportable au site concerné (maître ou abonné).
3. Synchroniser la base de données à l'aide du réplica transportable grâce à la fonction HSynchroniseRéplica.

• rplMaîtrePrioritaire : ce mode de réplication est le mode par défaut. Il permet de protéger la base de données du site "maître" des modifications apportées sur le site "abonné". Les modifications effectuées sur les sites abonnés ne seront donc pas propagées dans ce mode (seuls les ajouts seront propagés).
• rplAbonnéPrioritaire : ce mode de réplication rend le ou les sites abonnés prioritaires par rapport au site maître. Dans ce mode, le site maître n'est qu'une copie des différents abonnés mais ne propage pas les modifications entre les différents abonnés.
• rplPlusRécentPrioritaire : ce mode permet de propager toutes les modifications effectuées sur les bases de données. Ce mode de fonctionnement est celui à utiliser dans le cas où toutes les bases de données ont la même priorité (les modifications effectuées sont propagées sur toutes les bases de données).

• Vérifiez les fichiers répliqués. Tous les fichiers d'une base de données ne doivent pas obligatoirement être répliqués. Répliquez uniquement les fichiers de données nécessaires.
• Les échanges de fichiers ".rpa" ne sont pas obligatoirement symétriques : il est possible de créer et d'exécuter plusieurs journaux dans un sens sans créer ni exécuter un seul journal dans l'autre sens. Cependant, pour optimiser les performances, il est conseillé d'éviter d'effectuer des échanges toujours dans le même sens.
• La réplication respecte les filtres posés sur les tables ou les fichiers (sauf dans le cas de liaisons, pour respecter l'intégrité).
• Un filtre peut être mis en place du coté du maître : les abonnés recevront alors un sous-ensemble des données de la base maître. Dans ce cas, il n'est pas nécessaire de mettre en place un filtre du coté de la base abonnée.
  Si par le filtre, un enregistrement n'est plus "visible" sur la base de données maître, cet enregistrement sera considéré comme supprimé. Il sera alors automatiquement supprimé sur le poste abonné.
• La fonction HRecréeRéplicaAbonné permet de recréer un réplica abonné à partir du réplica maître.
• Prise en compte de la modification automatique des données (bases de données HFSQL Classic ou Client/Serveur) :
  Lors de la création du réplica abonné avec la fonction HCréeRéplicaAbonné, il est possible d'indiquer si la modification automatique des données doit être effectuée lors de la réplication. Dans ce cas :
  • Une modification de la structure de la base de données maître sera reportée sur la base de données abonnée. Cette opération sera effectuée lors de la réplication.
    Attention : Cette opération peut augmenter de façon significative le temps nécessaire à la réplication.
  • Les nouvelles rubriques seront prises en compte par la réplication.
  Remarques :
  • Le mécanisme ne fonctionne pas en cas d'ajout ou de suppression d'une clé unique.
  • Pour une réplication existante, il est nécessaire de recréer cette réplication (et notamment les abonnés) pour prendre en compte cette fonctionnalité.

• Chaque fichier ou table doit avoir au moins une rubrique clé unique.
• Il est nécessaire de pouvoir dater un enregistrement. Si la rubrique permettant de dater l'enregistrement est remplie automatiquement par un trigger, ce trigger doit être désactivé durant l'exécution de la fonction HSynchroniseRéplica (pour éviter de remplir cette rubrique avec la date de réplication).
  Remarque : Pour les bases de données HFSQL (Classic ou Client/Serveur), la rubrique permettant de dater l'enregistrement est automatiquement gérée.
• La réplication n'ouvre pas les fichiers ou les tables. Les fichiers ou les tables doivent avoir été ouverts par le programme avant de lancer la réplication.
• Pendant la réplication, l'occupation mémoire peut être très importante. Il est donc conseillé de répliquer uniquement les enregistrements nécessaires vers un poste abonné.
• Attention : cas spécifique : une partie seulement des tables reliées n'est pas répliquée. Dans ce cas, la réplication rejoue parfois certaines modifications comme un couple {ajout, suppression}. Si une table (non répliquée) est reliée avec l'option de modifications en cascade, les enregistrements reliés risquent d'être supprimés abusivement.
• La réplication ne sera pas effectuée dans le cas suivant : un des fichiers à répliquer est sécurisé, protégé par un mot de passe et il est utilisé dans une liaison comprenant des règles d'intégrité.