Vous n'êtes pas identifié(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.
Dernière modification par quintoux (17/10/2012 17:14:54)
Hors ligne
Bonjour,
Ça ne fonctionnera pas, à mon avis: si vous essayez de rejouer tous les ordres SQL générés sur tous vos postes clients sur la base, la probabilité d'obtenir le même résultat est assez faible, à moins peut-être que vous puissiez garantir qu'il n'y aura aucun conflit. Si vous voulez tracer les modifications dans une table, tracez les résultats (l'enregistrement à la fin de l'ordre par exemple) plutôt que l'ordre l'ayant généré. Ça sera déjà un peu plus robuste (et en plus, ça sera faisable avec un trigger). Mais il va y avoir beaucoup de travail, pour un résultat probablement hasardeux.
Sinon pour répondre à la question n°1, je ne crois pas qu'on puisse récupérer l'ordre SQL dans un trigger. Peut-être avec current_query() ?
Marc.
Hors ligne
Bonjour,
juste par curiosité quel est l'interet de faire ça ?
Les nomades changent de lieu tt le temps je suppose donc jamais la meme adresse ip vrai ?
Hors ligne
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
Hors ligne
un poste nomade c'est pas un serveur c'est un portable qui n'est jamais au même endroit c'est ça non ?
donc slony est a oublier sinon ça l'aurait fit 
Dernière modification par kenrio (19/10/2012 15:08:48)
Hors ligne
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.
Hors ligne
J'aurais pris le problème à l'envers et j'aurais fait une sorte de Cloud, mais je suppose que vous êtes bloqué à cause de l'application en frontale.
Dernière modification par kenrio (19/10/2012 16:56:10)
Hors ligne
oui tout à fait, on ne peut pas envisager cette solution
Hors ligne
