Discussion :

[jimmu.teno]

Bonsoir,

Je souhaite faire un programme qui permettrait aux commerciaux de récupérer les données d'une base qui se trouvent sur un serveur vers leur PC portable (base en local). A la fin de la journée, il synchronise les données de leur PC en local avec celles du serveur.

Questions :
1- Dois-je utiliser un système de réplication au niveau SQL serveur.
Base (serveur) <----- réplique --------> Base (local)
2- où dois-je créer un programme dotnet avec procédures stockées qui fassent les insert, update, delete ... avec DATASET ...
3- Comment gérer vous le cas des conflits de synchronisation ? ex si un commercial1 et 2 ont modifiés dans la journée les données d'un même client. Ex: deux adresses différentes. Lequel mettre sur le serveur ?
4- Il semblerait que la solution 1- est plus simple à mettre en place non ?

Merci de votre aide.

[tomlev]

La réplication n'est pas adaptée ici, vu que les commerciaux peuvent tous mettre à jour leur copie de la base.
Ce que tu peux faire, c'est détecter les mises à jour avec des triggers et les mettre dans une table d'évènements. Ensuite la procédure de synchronisation utilise cette table pour savoir ce qui a été modifié.
Pour les conflits, il n'y a aucun moyen de savoir quelle version garder il me semble... ça ne peut être fait que manuellement, puisqu'il faut prendre une décision arbitraire.

[jimmu.teno]

Bonsoir,

la réplication n'est pas adaptée à cause des conflits si je comprends bien.
Le serveur ne gère t-il pas une table des conflits pour qu'on puisse décider manuellement ?

Donc, le solution serait de mettre les nouvelles lignes, les mises à jour, les suppression dans une Table EVENT par ex. qui contient les colonnes :
n°ligne : date de copie : date de modification
Ensuite, une procédure stockée va lire la table EVENT en local et mettre à jour la Table sur le serveur (synchro). Les autres commerciaux idem (syncrho). Si des conflits existent, je renseigne la table des "Conflits" sur le serveur.
Ensuite, une fois que la gestion manuelle du conflit est fait, je relance une autre synchro sur les conflits... qui va mettre la table source à jour.
dites moi si c'est correct -

[tomlev]

Bonsoir,

la réplication n'est pas adaptée à cause des conflits si je comprends bien.
Le serveur ne gère t-il pas une table des conflits pour qu'on puisse décider manuellement ?

Je sais pas trop... pour moi, la réplication met à jour une base cible pour qu'elle soit identique à une base origine, mais c'est à sens unique. Enfin je me trompe peut-être...

Donc, le solution serait de mettre les nouvelles lignes, les mises à jour, les suppression dans une Table EVENT par ex. qui contient les colonnes :
n°ligne : date de copie : date de modification
Ensuite, une procédure stockée va lire la table EVENT en local et mettre à jour la Table sur le serveur (synchro). Les autres commerciaux idem (syncrho). Si des conflits existent, je renseigne la table des "Conflits" sur le serveur.
Ensuite, une fois que la gestion manuelle du conflit est fait, je relance une autre synchro sur les conflits... qui va mettre la table source à jour.
dites moi si c'est correct -

Oui c'est tout à fait ça.
Par contre tu vas recontrer un problème... je suppose que tes clients ont un ID unique ? Si c'est le cas, si 2 commerciaux créent chacun un client vont utiliser le même ID (en prenant la prochaine valeur disponible), et à la synchro ça va foirer... Il faut donc une autre façon d'identifier les clients de façon unique, par exemple en prenant en compte le nom du commercial ou quelque chose comme ça.

[jimmu.teno]

Pour la création d'un nouveau client, il y a peu de risque que dans une même journée deux commerciaux aillent chez un même client ... car dans mon cas, ils sont affectés à des secteurs géographiques différents.
Donc pas de soucis.
Merci de ton aide précieux.

[jimmu.teno]

J'ai une autre question qui fait suite à ce problème.

- Dois-je utiliser un Dataset pour transférer toutes les données de ma base ? (ce qui est peu problable sauf si vous me dites le contraire). En gros, est-ce que je peux copier une partie ou totalité de ma base serveur dans des Datasets. Les commerciaux travaille en local sur ces Dataset. Au retour au siège, ils synchronisent le Dataset avec le serveur. Est-ce possible ?

- ou dois-je créer sur chaque portable des commerciaux des répliques/copies de BDD. Ensuite, il mettent à jour la table des évéments durant la journée. De retour au siège, je me sers de cette table avec un script ASP.NET pour synchroniser du local vers le serveur ?

[tomlev]

Pour la création d'un nouveau client, il y a peu de risque que dans une même journée deux commerciaux aillent chez un même client ... car dans mon cas, ils sont affectés à des secteurs géographiques différents.

Je crois que tu as mal compris ce que je disais... je ne parle pas du nom du client, mais de son ID. Dans la base de données tu as généralement un numéro qui sert d'identifiant unique. Supposons qu'au début de la journée, 2 commerciaux A et B partent avec une base à jour qui contient 200 clients, numérotés de 1 à 200. Le commercial A va chez M. Dupont, et l'enregistre dans sa base locale avec l'ID 201. Le commercial B va chez M. Durand, et l'enregistre aussi avec l'ID 201. Au moment de la synchro, il y a donc 2 clients avec le même ID, il faut donc un mécanisme pour attribuer un nouvel ID à l'un des 2...

Pour l'utilisation d'un dataset ou d'un BDD locale, il n'y a pas vraiment de règle générale... les 2 solutions me semblent valables, à toi de voir celle que tu préfères.

[Bluedeep]

il faut donc un mécanisme pour attribuer un nouvel ID à l'un des 2...

Il suffit d'utiliser les GUID comme PK, et ainsi plus de problème à la synchro.