Vous n'êtes pas identifié(e).
Pages : 1
oui tout à fait, on ne peut pas envisager cette solution
oui je suis tout a fait d'accord
Il y a des utilisateurs qui vont saisir des info sur poste nomade (donc sur une base locale actualisé lors de leur derniere synchronisation avec les infos de la base centrale).
Comment permettre la meilleure fonctionnalité de la synchronisation sachant que certains vont synchroniser 1 fois par semaine, d'autres 1 fois tous les jours, .... avec le MINIMUM de perte d'infos car certaines infos peuvent etre impactés par plusieurs utilisateurs.
heu, au niveau de la meme adresse ip, c'est une notion que je ne stocke pas donc je comprends pas la question.
En fait, je veux pouvoir utiliser le meilleur moyen pour synchroniser les informations modifiées par chaque poste nomade sur la base centrale (et inversement).
J'avais détaillé tout mon processus prévisionnel mais je ne sais pas comment faire car je ne pense pas qu'il y ait de solutions opérationnelle pour la synchronisation sANS perte de données.
Quelqu'un a -t-il une idée
Bonjour,
Explication : 1 Base sur un serveur MAITRE et N postes nomades qui enregistrent des infos en mode déconnecté.
La base ve etre migrée sur POSTGRESQL et on est sous WINDOWS.
N'ayant pas trouvé d'outils pouvant répondre à nos besoins (Symétriques, asynchrone et windows), nous avons opté pour la méthode suivante.
Mon principe de fonctionnement en 2 temps (mais je ne sais pas si c'est possible car je ne connais pas postgresql ni les triggers) :
1) Lors de la saisie, modif et suppression (que ce soit en mode connecté ou nomade), un trigger devra insérer dans une table les infos suivantes : l'utilisateur connecté, un numéro sequentiel, l'ordre SQL effectué complet et d'autres infos (comme date_heure, OK_maitre, OK_nomade...) .... possible ou pas ???? (ainsi si on est sur le poste maitre, cette table contiendra les mises à jour et création faites sur la base centrale qu'il faut envoyer à TOUS les postes abonnés .... si on est sur un poste nomade, cette table contiendra toutes les mises à jour à envoyer au serveur central qui ensuite les repercutera sur tous les autres postes nomades)
2) Une tache planifiée journalière sur le serveur CENTRAL devra permettre :
a) de recupérer le fichier envoyé par chaque abonné (dans la journée) contenant l'id utilisateur et la date de la veille pour qu'on puisse préciser que l'abonné a envoyé ses mises à jour à telle date (le serveur central devra utiliser cette info pour mettre à jour la table de DATE_des_SYNCHROS).
b) de récupérer le fichier envoyé par chaque abonné (dans la journée) contenant la table remplis par le trigger de chaque abonné.
c) le central doit mettre a jour la base CENTRALE en intégrant tous les ordres sql contenus dans les fichiers des nomades ??? à ce niveau, c'est le serveur POSTGRESQL qui devra faire les mises à jour ... possible ???)
d) de déposer sur un FTP commun, le fichier des mises à jour pour chaque abonné (a ce niveau, j'ai prévu qu'un fichier soit fait par abonné et qu'il contienne toutes les intégration qui ont été faites dans la base centrale et dont l'abonné n'a pas connaissance grace à sa date de derniere mise à jour).
3) Sur le poste nomade, lorsqu'il clique sur le bouton synchro :
a) recupération du fichier mis à disposition par le central sur le FTP pour l'abonné en question et qui contient les ordres sql à executer sur le poste abonné.
b) execution de ces mises à jour sur le poste abonné
c) export sur le ftp central, du fichier contenant la date de mise a jour de cet abonné
d) export sur le ftp central, du fichier contenant les mises a jour effectués sur le poste nomade qu'il faut impacter sur la base centrale.
J'ai essayé d'expliquer ma méthode .... est- ce que j'ai été clair ???? je ne sais pas mais n'hésitez pas à poser des questions pour que j'explique au mieux mon problème qui est en fait de connaitre la faisabilité de ce projet ???
Merci d'avance car je suis un peu dans l'inconnu.
Pages : 1
