Synchro BDD SQL Compact et SQL Server

Bonjour,

Je suis à la recherche d'un moyen de synchronisation entre plusieurs clients disposant de leur propre BDD locale (SQL CE) et d'un server de stockage (SQL Server 2008) regroupant tranquillement les données de tous ces gentils clients.
Les clients étant 95% du temps hors connexion, l'idée ici serait de pouvoir synchroniser les données avec le serveur pour qu'ils puissent faire bosser hors connexion et de sauvegarder les modifications éventuelles sur le serveur une fois qu'une connexion est disponible. Naturellement, chaque client peut modifier les données de tout un chacun, ce qui complique quelque peu le projet....

Que pourrais-je utiliser comme moyen pour y parvenir ?

Avant d'aller plus loin, il faut déjà que tu définisses une stratégie de synchronisation. Comme tu l'as dit, pendant que certains clients sont hors ligne, d'autres peuvent se connecter et mettre à jour des données. Dès lors, comment doivent être gérés les conflits ?

Une stratégie assez classique, utilisée par exemple sur Dynamics CRM, c'est de dire que le dernier à mettre à jour a raison. Donc si un client A se connecte à 10h00, il va mettre jour les données. Puis à 10h30 un client B se connecte, alors le système sera mis à jour avec les données de B, et celles de A seront écrasées.

Je te conseille de bien y penser, sous tous les angles, et une fois que tu auras les idées claires là-dessus, de te lancer dans les développements. Pour ces derniers, tu peux utiliser par exemple Microsoft Sync Framework, et voir notamment ce qui est proposé pour la synchronisation de bases de données.

Citation:

---

Envoyé par DotNetMatt

Avant d'aller plus loin, il faut déjà que tu définisses une stratégie de synchronisation. Comme tu l'as dit, pendant que certains clients sont hors ligne, d'autres peuvent se connecter et mettre à jour des données. Dès lors, comment doivent être gérés les conflits ?

Une stratégie assez classique, utilisée par exemple sur Dynamics CRM, c'est de dire que le dernier à mettre à jour a raison. Donc si un client A se connecte à 10h00, il va mettre jour les données. Puis à 10h30 un client B se connecte, alors le système sera mis à jour avec les données de B, et celles de A seront écrasées.

Je te conseille de bien y penser, sous tous les angles, et une fois que tu auras les idées claires là-dessus, de te lancer dans les développements. Pour ces derniers, tu peux utiliser par exemple Microsoft Sync Framework, et voir notamment ce qui est proposé pour la synchronisation de bases de données.

---

Merci pour ta réponse.
Hormis certains cas isolés, la modification des données ne sera accessible que par l'utilisateur original. La stratégie de surcharge par le dernier client me va très bien.
Par ailleurs, j'avais un doute sur l'insertion des nouvelles données. Si le client A travaille hors connexion sur une table "Planning" et y ajoute une nouvelle ligne d'id 5 (par exemple) et que B de son côté ajoute également une ligne d'id 5 (en supposant que les deux ont synchronisé peu avant), quel sera le comportement du système proposé par Sync Framework ?

Concernant le choix de la PK, déjà tout dépend du mode de synchronisation. D'une manière générale, si tu es en synchro unilatérale (client vers serveur) alors il est conseillé d'utiliser un entier en auto-incrément, et dans les scénarios bilatéraux (client vers serveur et serveur vers client) il est conseillé de privilégier les GUIDs. Voir ici : Selecting an Appropriate Primary Key for a Distributed Environment. Ce ne sont que des conseils, ensuite il faut voir en fonction du projet bien sûr...

Enfin Sync Framework propose 4 mode de gestion des conflits. Tu en sauras plus en consultant cet article : Handling Data Conflicts in the Microsoft Sync Framework (4 pages).

Merci pour ta réponse. J'ai étudié les liens que tu as mis à disposition avec attention.
Dans ce cas précis, je suppose que la transaction sera bidirectionnelle étant donné que les clients enverront leurs différentes modifications/insertions au serveur et qu'à chaque synchronisation ces derniers récupèrent la totalité des données du serveur pour avoir accès aux données de leurs confrères clients.
Ca s'annonce compliqué en tout cas...

Est-il possible de maintenir les types int classique pour les PK dans le cadre de synchronisations ?
L'utilisation de GUID étant plus complexe et plus encombrante, je me renseigne avant de modifier les clés primaires de mes tables et d'ajouter du code.

Oui c'est possible, comme indiqué plus haut il s'agit juste de conseils. Il faut adapter en fonction de ton projet. Peut-être que dans certains cas tu seras obligé d'utiliser des GUIDs et dans d'autres un simple Int fera l'affaire...

Si tu veux choisir en toute connaissance de cause, voici un peu de lecture : What should I choose for my primary key?.

Bonjour,
J'ai effectué quelques tests de synchro d'une table sur ma machine de dev et ça fonctionne plutôt bien. Cependant, lorsque je teste sur un autre poste, j'obtiens l'erreur suivante:
"Retrieving the COM class factory for component with CLSID failed due to the following error: 80040154."

Il semblerait qu'un conflit d'architecture soit en cause mais impossible de régler ça. Est-il nécessaire d'installer le SDK MSSync pour palier à ce problème ? La solution complète étant destinée à l'usage nomade, j'aimerai éviter de devoir faire installer des outils tierce par les postes clients...

D'après la doc MSDN il s'agit d'un problème d'installation :

Citation:

---

Envoyé par MSDN

Managed Application Throws System.Runtime.InteropServices.COMException (0x80040154)

A managed synchronization application throws System.Runtime.InteropServices.COMException with the following error message: "Retrieving the COM class factory for component with CLSID {565AEDBF-3108-4405-AF1F-9C2C25925DAE} failed due to the following error: 80040154."

This exception occurs when an unmanaged synchronization component, such as Synchronization.dll, is missing from the installation. This can occur when Sync Framework has been uninstalled or when installation was not completed successfully.

Solution
Reinstall Sync Framework. Sync Framework can be downloaded from this Microsoft Web site.

---

Je confirme, l'installation de la version 67Bits du MS Sync core règle le souci. Ya t-il cependant un moyen de déployer le Framework sur des clients sans passer par le MSI?
Merci pour ton aide en tout cas.

[EDIT]
Bonjour,

Toujours dans l'aventure de la sync' mais ça avance.

Question : une fois les scopes crées, la synchronisation terminée, est-il plus judicieux de garder les scopes pour une prochaine synchronisation ou les désapprovisionner pour libérer la place ?

Bon merci pour ton aide en tout cas cher ami.

Pour le déploiement client, je n'en ai aucune idée...

Concernant les scopes, c'est à toi de voir s'il est judicieux de les conserver ou non. Tu trouveras plus d'info sur la MSDN, dans un chapitre du lien initial que j'ai indiqué ici. N'hésite pas à fouiller dans cette doc c'est très complet. Voici le lien : Provisioning for Synchronization (SQL Server).