Discussion :

[R&B]

Au sujet de la Réplication Universelle Assistée Automatique (RUAA dans le titre, ça le fait !),
J'ai un projet en HFSQL Classic, une réplication décrite (WER) pour que la base maitre en HFSQL Classic.
Premier problème, en suivant les instructions : le réplica maitre ne se crée car ReplicAdmin ne trouve rien dans mon exécutable (bien installé via WDSetup).
Le projet suit à priori correctement les limitations de ce mode (pas de relocalisation des données, rien !)
Le but est de faire un projet référence pour comparer les modèles de réplication et servir de référence à une réplication programmée.

Quelqu'un a-t il eu la chance de mettre cela en mouvement ? Et donc aura trouvé une raison au silence de ReplicAdmin ?

ps : je vais sans doute laisser ce fil ouvert un moment...

///--- réponse 1
- Première évolution : décrire le .WER non pas depuis ReplicEdit mais directement depuis le projet, outils, réplication : replicEdit.
- Seconde évolution : ne pas laisser complètement la main à l'installation... individuelle + standard + répertoire.
Y inclure le .WER, intégrer les modules de réplications...
Pour la RUA : Méthode d'accès directe à la base maitre + Fixer les paramètre de la base maitre lors de l'installation + tout cocher (mode connecté + synchro auto + modif à l'installation + écraser ces valeurs)

Résultat : ReplicAcdmin trouve enfin une réplication mais travaille... dans ProgramData (contrairement à ce qui est prévu)

///--- réponse 2
- Troisième évolution : utiliser non pas l'assistant de création de procédure d'installation (Projet, Procédure d'installation) mais l'outil WDinst (outils) pour modifier votre installation et définir les emplacement des bases Maître et locales (onglet réplication) si on ne souhaite pas travailler dans ProgramData.

Il faut ensuite

• créer le répertoire pour la base maitre.
• Installer et lancer votre projet qui normalement comporte un HCréationSiInexistant et copier les fichiers dans la base maître.
• A partir de la soit on a autorisé le mode connecté / mode autonome (ReplicAdmin voyant enfin la réplication, on peut intervenir)... En connecté l'ouverture et la fermeture du projet synchronise !!!!

Le lancement poste encode un problème à régler... la création des fichier est nécessaire AVANT la réplication. et le mode automatique déclenche la synchronisation Avant le projet, on a donc toujours (que ce soit pour la base maitre ou un poste supplémentaire), les fichier du nouvel arrivant qui manquent.

///--- réponse 3 : réplication universelle assistée programmée RUAP
Dans le projet ajout d'un bouton avec le code de l'aide qui initialise la réplication si elle ne l'a pas été et déclenche la synchronisation. C'est le mode programmé !
Dans l'installation, joindre le WER et les outils mais indiquer que le programme ne gère pas la réplication. En effet, WDSetup n'ira donc pas modifier le programme pour ajouter les réplication en ouverture fermeture puisque c'est programmé. (pour ceux que cela choque : OUI WDSetup modifie l'exécutable sur le poste... pour prendre en compte les paramètres fixés par l'installation).
En fonctionnement : toujours le problème d'initialisation de la base maître. Pour le reste, c'est bonheur !
En effet, les fonctions utilisent un sous répertoire de l'application qui pose aucun problème avec l'UAC... et la réplication est à la disposition de l'utilisateur.
Cette fois on peut considérer que l'on réplique les informations : le contrat est rempli.

Allez plus loin n'est pas possible en réplication universelle assistée car l'assistance implique précisément que les informations de topologie soient intégrées aux programmes. Ainsi tous les postes doivent présenter les mêmes chemins et accéder au même partage. Mais les données sont bien répliquées...

Bonus :
1- pour ceux que cela inquiète, ce projet exemple utilise les IDAuto HFSQL comme clés uniques et éléments de relations (contrainte inhérente à la réplication qui n'est pas indiqué clairement dans la documentation qui présente qu'aucune modification du projet n'est nécessaire... chacun comprends avec son référentiel). Ce mode de réplication a montré que chaque poste utilise une plage différente d'identifiants automatiques pour les fichiers répliqués... évitant ainsi les collisions.
2- Nous n'avons rencontrés qu'un problème avec le mode automatique : quand on passe en déconnecté sans avoir lancé une réplication avant, on a réussi à générer des doublons d'IDAuto... qui ont été résolus par une nouvelle réplication (en relançant l'application). On peut considérer que c'est une simple erreur de procédure.

Le fil passe en résolu : la RUA a fonctionné !

[R&B]

Concernant cette fois la réplication universelle programmée, on a généré le réplica maitre (RPM) et quelques réplicas abonnés (RPL)

Admettons qu'on ai mémorisé les paramètres des réplicas abonnés : liste des fichiers, sens conflit relation et exclusions de rubriques.
Soit dit en passant, comment cela est-il normalement mémorisé, la création du réplica abonné ne permet de ne mémoriser que la liste des fichier mais je n'ai rien trouvé sur les relations/filtres/rubriques et autres surcharge de paramétrage du sens et des conflits. On a du imaginer un stockage.

La question est : quand active-t on ces paramètres ?
Ai je bien compris qu'on a besoin de connaitre cela pour générer les réplicas transportables et pour les intégrer...
ainsi donc en amont des HCréeRéplicaTransportable et HSynchroniseRéplica ?

Je suis très étonné de ne strictement rien lire autre que la documentation sur ce sujet...

[R&B]

... Suite du monologue...

J'ai monté un mécanisme qui permet la mémorisation des paramètres fins d'une réplication : liste des fichiers, sens, conflit, rubriques et filtres
Avant la création du réplica transportable, je permet la prise en compte de s ces paramètres via les fonctions HRplGestion* et la compilation de procédure pour les filtres.
La création du réplica maitre semble tenir compte ce tout cela. Mais je me trouve dans une situation cocasse lors de la synchronisation de l'abonné.
Que je remonte les mêmes règles pour la réplication ou pas, le résultat et le même : HSynchroniseRéplica ne fonctionne plus.
C'est à dire qu'il retourne un vrai, et pas d'erreur mais le fichier abonné restes désespérément vide.

A noter que j'utilise la même syntaxe (et localisation de fichiers RPA/RPL etc) que pour la version sans description détaillée.
Mieux le paramétrage d'une réplication simple (fichier uniquement ver l'abonné) ne donne rien.

Pas d'erreur mais pas de donnée = résultat peu encourageant

[serendib]

Regarde du côté de cette répli open source en windev.

http://fabriceharari.com/

[R&B]

Salut serendib et merci.
J'ai cependant déjà étudié ce très bon projet de fond en comble et ai pu converser avec Fabrice à ce sujet.
C'est, soit dit en passant, grâce à ce projet que j'ai pu commencer à appréhender sérieusement ce sujet.

Cette étude de la réplication ayant pour cible une topologie précise, je ne puis écarter aucune voie, ce fil traite donc de celles avec HFSQL.
- Les assistées sont trop restrictives mais permettent bien de faire des petites choses sans effort.
- J'ai le sentiment que l'universelle programmée est une solution 'entre deux' : une réminiscence de ce que fut le premier essais avec la réplication journalée et les assistées.
Du coup on accède aux commandes pour la réaliser mais on ne trouve pas la manière de les assembler.
Cherchez les HRplGestion* pour affiner la sélection de ce que vous souhaitez répliquer, c'est un vide sidéral : la doc de la fonction ou les aspirateurs web de ladite doc.
- j'ai aussi analysé le guide de toto42 mais il ne gère malheureusement pas ces paramètres 'fin' (fichiers, liaisons, sens, conflit, rubriques, filtres) que l'on peut théoriquement fixer par programmation.

Dans mes essais, j'ai réussi à remonter les données des abonnés, je dois encore vérifier que mes réglages sont vérifiés. Pour ce qui est du sens maitre-abonné, c'est l'import à l'abonné qui ne passe encore pas.

[R&B]

De retour sur la RUP (Réplication universelle programmée)

Après (re)lecture de la documentation, la création l'abonné doit être accompagnée de l'attribution d'une base chez le maitre.
Une fois initialisée par des HCréation, on doit remplir cette base avec un premier réplica du maitre. L'idéal est alors d'avoir déjà des données pour chaque fichier (même inutiles).
On passe alors par la création d'un réplica transportable au maitre (ver cet abonné) et sa synchronisation immédiate dans cette base.
C'est cette base qui est alors envoyée, accompagné du .RPL et du .SYN à l'abonné par FTP.

Sur le poste de l'abonné le projet peut alors fonctionner, les créations d'enregistrement suivent bien les plages d'IDAuto fixées par la réplication pour l'abonné.
Mon problème actuel survient lors de la réplication des données de l'abonné vers le maître.
Dans le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lb_Ok = HCréeRéplicaTransportable(lc_Replica, ln_RUID,"", "")

lc_Replica contient le chemin complet du réplica abonné.
ln_RUID est l'identifiant de l'abonné.
lb_Ok est à faut avec une erreur code 180323 de wd200rpl.dll (20.0.15.0)
information de débogage : FLE115
"Impossible d'ouvrir le fichier <répertoire du Rpl sans le nom du rpl>"
Mes recherches sur le sujet font bien par de l'erreur 180323 mais aucunement d'une solution. je passe par le ST mais cela commence à poser des problèmes de temps, délais.