Bonjour,

Après analyse de nos besoins , on c'est rendu compte que la réplication était trop lourde (bcp trop de données).
Ce que l'on aimerait faire , c'est que commercial rentre au site de l'entreprise, qu'il ne prenne le dossier des clients qu'il va visiter durant la journée et que a ce moment la plus personne ne puisse modifier les données des clients prisent par le commercial, et quand le commercial revient il remet les données dans la base centrale.
il y a t'il moyen de faire cela facilement en Windev, j'ai cherché mais j'ai pas trouvé un moyen simple.

Bonjour
Pourquoi ne pas développer une base pour la gestion de ce système tampon ? Le contrôle d'accès peut alors être effectué par les triggers (ordre HLLitxx + identifiant trouvé dans le tampon = bloqué par utilisateur). Si cela apporte une pseudo lourdeur, vous aurez alors la maîtrise complète (programmée par vous) de vos données "exportées".

Nous n'entrons volontairement dans les détails mais l'idée est d'ajouter à votre projet une base des données exportées ne contenant que les identifiants des enregistrements retenus.
Cette base, alimentée lors de l'export, aura deux utilités :
- assurer le contrôle d'accès pour les utilisateurs 'sédentaires'
- proposer un outil pour la comparaison des données lors de l'importation où vous pourrez distinguer les informations créés, modifiées et supprimées (mais le mieux est sans doute de mettre tout cela dans une base dédiée du poste itinérant)

Donc je dois écrire la fonction de réplication, Windev ne dispose pas de fonctions spécifiques.

Pardon mais je ne suis plus,
Si la réplication WinDev est trop lourde, alors il vous faut inventer une solution alternative plus adaptée à vos besoins. C'était l'objet de la proposition.
Pour utiliser les fonctions intégrées de réplication il faut en acceter la lourdeur pré-citée...

ps: Quand vous indiquez ré-écrire, je met un bémol.
Vous ne perdrez de temps à cela car :
- cela ne demande pas un effort inconsidéré, juste un peu d'imagination pour concevoir une solution optimale coté performance
- vous aurez la maîtrise de cet élément stratégique dans vos procéssus.

Biensûr, il vous faut prévoir une phase d'adaptation à tout les cas possibles mais (pour avoir monté un mécanisme apparenté) le jeux en vaut la chandelle, car quand votre processus marche, il marche et ne dépend pas d'une mise à jour à valider...

excusez-moi , je voulais plutot dire, si il existait déjà quelque chose de prévu pour faire cela dans Windev , je me rencompte que non, donc je vais développez cela par moi même.

Bonjour
je suis en train de voir justement pour moi.
Comme vous je trouve que la réplication est un peu lourde. Voici mes premières idées. Je ne dis pas que c'est la solution.

Je garde la notion de maître (M) et d'esclaves (E].

Dans l'ana je rajoute des boolééens pour identifier les nouveaux rec rajoutés dans les E.
Lors de la synchro qui fonctionnera dans les deux sens de M > E et E >M il suffira de rechercher ces boolléens et une fois les copies de rec déterminés on se deconnecte des fichiers HF et on copie les fichiers HF du M vers l'E et cela devrait fonctionner.

Si vous pensez avoir mieux je suis preneur

Cdl
William

William

Citation :

La synchronisation se fait par programmation ou il y a déjà quelque chose d'implémenter dans windev pour contrôler les données au moment de la synchronisation

@ Litbos
Citation :
C'est que William est en train de reprogrammer la chose...

@ William
Mieux ? qui sait?
Dans le cas de notre synchronisation bi-directionnelle nous utilisons un répertoire commun dans lequel se trouve une 'copie' de la base de donnée. En fait, il s'agit d'un ensemble de fichier contenant les identifiant, les ordres d'écritures CMSR (Création/Modification/Suppression/Recodification), le destinataires (nous synchronisaons plusieures bases) et quelques infos utiles pour le traitement. Ces fichiers tampon sont alimentés via trigger de manière uniquement séquentielle.
La récupération filtre les enregistrement dont le destinataire correspond et traite les enregistrements dans l'ordre séquentiel. Une fois traité, le bloc est supprimé. les ordres suivants seront traités lors de la prochaine récupération...

Astuce : les fichiers tampons sont en ajout uniquement : jamais de modification d'enregistrement, soit autant d'ordre que d'écritures fichiers.

Unique difficulté : la gestion des triggers qui n'autorisent en théorie qu'une fonction par ordre surveillé pour un fichier (mais un mécanisme de pool avec activation à la demande a été étudié mais pas réalisé faute de temps.

au final, notre synchronisation marche fort bien dans les deux sens. Evidement il fut prévoir des règles de gestion pour éviter la création de doublons... en passant peut être par des identification temporaire dans les postes itinérant.
La synchronisation envéra alors les nouvelles données dans la base de nouveau avec les identifiant définitifs.

Re
tape "réplica" dans l'aide et tu vas voir que WD peut le faire mais je trouve tout cela trop lourd et puis pas la main lorsque cela ne marchera plus comme tu le vx.

cdl
William