Replication Fusion SQLServer Compact

2010
Wygwam
Par Pierre Cambier
.NET & Windows Mobile Solution Developer
Microsoft Certified Technology Specialist
[LA REPLICATION DE FUSION AVEC SQL

SERVER COMPACT : IMPLEMENTATION
ET CONSEILS]
La réplication de fusion Microsoft est un produit puissant qui permet de synchroniser des données
entre plusieurs bases. La réplication de fusion avec SQL Server Compact permet d’assurer les
échanges de données entre une base de données serveur et les différentes bases mobiles sur les
terminaux portables. Cet article présente les grands concepts de la réplication de fusion ainsi que les
spécificités de son implémentation dans le cadre de projets mobiles. Il expose notamment de
nombreuses préconisations en se basant sur un exemple concret de projet mobile.
www.wygwam.com
Wygwam
Où nous trouver…
Wygwam – Lille Wygwam – Paris

Euratechnologies 26-28, rue de Londres
165, avenue de la Bretagne 75009 PARIS (France)
59000 LILLE (France) info@wygwam.com
+33 20 82 38 77
info@wygwam.com
Wygwam – Belux Wygwam – Suisse

64, rue Victor Corne 9, route des Jeunes
7700 MOUSCRON (Belgique) 1227 ACACIAS-CAROUGE (Suisse)
+32 56 33 06 60 +41 22 300 04 10
info@wygwam.com info@wygwam.com
2 La réplication de fusion avec SQL Server Compact : Implémentation et conseils | Pierre Cambier - Wygwam
www.wygwam.com
Sommaire
I. Présentation de l’article .................................................................................................................. 5
II. Principes de la réplication de fusion ............................................................................................... 6
A. Généralités .................................................................................................................................. 6
B. Vocabulaire.................................................................................................................................. 6
C. Publisher, Distributor et Subscriber ............................................................................................ 7
D. Notion de snapshots.................................................................................................................... 7
E. Déroulement des synchronisations ............................................................................................. 8
III. Spécificité de la réplication avec SQL Server Compact ............................................................. 10
A. Réplication entre un serveur et des terminaux mobiles ........................................................... 10
B. Restrictions et limitations.......................................................................................................... 11
C. Pré-requis .................................................................................................................................. 11
D. Installation et déploiement sur un terminal mobile ................................................................. 12
IV. Cas d’étude - Base TECHNOMADE ............................................................................................ 13
A. Description du projet................................................................................................................. 13
B. Description de la base TECHNOMADE ...................................................................................... 15
C. Installation de la base TECHNOMADE ....................................................................................... 17
V. Configuration du Distributor ......................................................................................................... 18
VI. Configuration des publications.................................................................................................. 26
A. Notion de publication ................................................................................................................ 26
B. Création d’une nouvelle publication via le wizard .................................................................... 26
C. Définition des articles ................................................................................................................ 29
D. Définition d’un système de filtres ............................................................................................. 34
E. Propriétés de l’agent de snapshots ........................................................................................... 42
F. Fin de la création de la publication ........................................................................................... 44
G. Génération du snapshot principal ............................................................................................. 46
H. Modification une publication .................................................................................................... 48
I. Suppression d’une publication .................................................................................................. 51
VII. Propriétés avancées des publications ....................................................................................... 52
A. Modification du répertoire de snapshots ................................................................................. 52
B. Définition de la période de rétention........................................................................................ 53
C. Options des abonnements ........................................................................................................ 54
www.wygwam.com
D. Notions de partitions ................................................................................................................. 55

VIII. Configuration de la synchronisation web.................................................................................. 60
A. Configuration de IIS ................................................................................................................... 60
B. Test de la synchro web .............................................................................................................. 69
IX. Utilisation de la réplication dans le code .NET d’une application mobile ................................. 79
A. Présentation de la classe SqlCeReplication ............................................................................... 79
B. Mise en action de la réplication dans le code .NET ................................................................... 82
C. Exemple d’exécution de la réplication en mode asynchrone ................................................... 88
D. Réinitialisation d’un abonnement ............................................................................................. 93
X. Monitoring des synchronisations .................................................................................................. 95
XI. Gestion des conflits ................................................................................................................. 101
A. Comment naissent les conflits?............................................................................................... 101
B. Détection de conflits et niveaux de suivi................................................................................. 103
C. Résolution de conflits et résolveurs ........................................................................................ 104
D. Rédaction d’un résolveur personnalisé ................................................................................... 107
XII. Scripts SQL et procédures stockées pour la replication .......................................................... 114
A. Génération d’un script de création de publication ................................................................. 114
B. Publications et procédures stockées ....................................................................................... 116
C. Autres procédures stockées utiles .......................................................................................... 120
XIII. Optimisation des performances, problématique de la volumétrie......................................... 121
A. Problématique ......................................................................................................................... 121
B. Activation de l’option « Precompute partitions » ................................................................... 122
C. Simplification du système de filtres ........................................................................................ 124
D. Optimisations avancées........................................................................................................... 126
E. Profil de distribution................................................................................................................ 132
F. Autres préconisations serveur ................................................................................................ 136
XIV. Conclusion ............................................................................................................................... 137
XV. Remerciements ....................................................................................................................... 137
www.wygwam.com
I. Présentation de l’article
Cet article explique l’implémentation d’un système de synchronisation de données entre des
terminaux mobiles et un serveur, en utilisant la réplication de fusion SQL (merge replication) entre
une base centrale SQL Server et des bases mobiles SQL Server Compact.
Il décrit pas à pas les étapes de configuration nécessaires au bon fonctionnement d’un système de
réplication.
Cet article se base sur un exemple concret de projet mobile pour exposer les grands concepts de la
construction d’un système de réplication adéquat. Nous allons ainsi imaginer que nous devons
mettre en place un système de synchronisation pour des techniciens nomades qui doivent réaliser
des interventions de maintenance chez des clients (plomberie, électricité, etc.…).
La réplication SQL est un produit fiable, intéressant, mais qui peut parfois se révéler complexe en
termes de configuration et de maintenance, surtout dans le cas de grandes volumétries de données.
C’est pourquoi cet article aborde cette problématique et propose de nombreuses préconisations afin
d’optimiser au mieux les performances du système.
Cet article est non seulement destiné aux personnes qui ne connaissent pas la réplication de fusion,
mais également aux informaticiens plus expérimentés.
Pré-requis nécessaires :
• Notions en développement d’applications .NET avec Visual Studio.

• Connaissances minimales de SQL Server (2005 ou 2008 conseillé).
• Maitrise de l’interface « Microsoft SQL Server Management Studio » conseillée.
Bonne lecture !
Légende :
Ceci est une information ou une remarque qui n’est pas importante.
Ceci est un conseil, une astuce, ou un point important.
Ceci est une remarque importante, à laquelle il faut faire très attention.
www.wygwam.com
II. Principes de la réplication de fusion
A. Généralités
La réplication de fusion (merge replication) est un système puissant et riche en fonctionnalités qui
permet la synchronisation de données entre une base centrale et plusieurs bases répliquées.
Lors du processus de réplication, seules les données modifiées (par des ordres UPDATE, INSERT, ou
DELETE) sont prises en compte. Le système peut déterminer de manière intelligente quelles sont les
données modifiées et quelles sont les données qui doivent être envoyées sur les bases répliquées.
La réplication SQL offre la possibilité importante d’implémenter un système de filtres complet afin de
distribuer au mieux les données sur les différentes bases. Ce qui fait également la force de la
réplication, c’est qu’elle offre de nombreux outils d’aide à la résolution de conflits. Il sera d’ailleurs
possible d’éviter toute sorte de conflits en paramétrant convenablement le système de
synchronisation, et plus particulièrement les différentes publications (Cf. chapitre VI).
B. Vocabulaire
La réplication de fusion est une fonctionnalité de SQL Server à part entière. Elle dispose de son
propre vocabulaire. Il est important de connaitre ce vocabulaire pour la compréhension de l’article.
Publisher Il s’agit de la base publiée, c'est-à-dire celle qui va être répliquée.

Distributor Il s’agit de la base de distribution, celle qui va être chargée de gérer la
distribution des données vers les subscribers.
Subscribers (ou Abonnés) Il s’agit des bases qui vont recevoir les données répliquées.
Dans notre article, les abonnés sont les terminaux mobiles.
Subscription (ou Abonnement) Demande de remise d’une copie de la publication à
l’abonné.
Snapshot Un snapshot est un ensemble de métadonnées qui vont être utilisées lors
des synchronisations.
Publication Une publication définit une liste d’éléments qui doivent être répliqués
vers les abonnés. Elle définit aussi un ensemble d’options importantes
(filtres, partitions, flux, etc.…)
Article Un article est une table de la base publisher qui doit être répliquée. La
publication est un ensemble d’articles.
Partition Il s’agit d’un ensemble de lignes ou de colonnes pour un abonné
spécifique.
www.wygwam.com
C. Publisher, Distributor et Subscriber
La notion de réplication SQL passe obligatoirement par les notions de « Publisher », « Distributor »
et « Subscriber ».
Il s’agit en fait de 3 parties distinctes ayant chacune un rôle précis dans les process de
synchronisations. Ces 3 parties correspondent d’ailleurs à 3 bases de données différentes.
Pour rappel, le publisher correspond à la base publiée, c’est à dire celle qui contient les données à
répliquer. Le distributor correspond à la base qui distribue les données (base système), tandis que le
subscriber (ou abonné) correspond à la base répliquée, c’est à dire celle qui reçoit les données
répliquées. A noter que le publisher et le distributor peuvent être configurés sur le même serveur.
C’est toujours aux subscribers que revient la tache d’initialiser une synchronisation avec
le publisher.
D. Notion de snapshots
Les snapshots sont des métadonnées utilisées lors des synchronisations et sont exposées sur le
serveur SQL.
Les snapshots permettent de définir le schéma de la base à un instant t, ainsi que l’ensemble des
contraintes liées.
Il existe 2 types de snapshots:
• Le snapshot principal qui doit être généré obligatoirement suite à la mise en place d’une
publication.
• Un snapshot spécifique par abonné, lié à une partition (système de partitions) (Cf. chapitre
VII.D.).
Les synchronisations de données entre le PDA et le serveur SQL se basent sur ces snapshots.
www.wygwam.com
E. Déroulement des synchronisations
Synchronisation initiale :
Voici comment se déroule la première synchronisation :
• Le distributor utilise le répertoire de snapshots pour préparer le schéma de la base

répliquée.
• Le schéma de la base mobile est créé.
• Les contraintes sont créées sur la base répliquée.
• Les données sont téléchargées.
www.wygwam.com
Synchronisations suivantes :
Lors des synchronisations suivantes, le distributor n’utilise plus les snapshots. Seul le différentiel
des données est téléchargé.
www.wygwam.com
III. Spécificité de la réplication avec SQL Server Compact
A. Réplication entre un serveur et des terminaux mobiles
Dans le cadre de projets mobiles, la réplication de fusion s’établit entre un serveur SQL Server et
plusieurs bases mobiles de type SQL Server Compact.
Chaque terminal possède une base de données SQL Server Compact, répliquée à partir d’une base de
données SQL Server. Les bases SQL Server Compact représentent donc les abonnés aux publications
serveur.
Ces bases SQL Server Compact peuvent être :
• soit générées directement sur les terminaux par réplication SQL lors de la première
utilisation d’une application mobile par exemple,
• soit déployées directement avec une application mobile
Pour les projets mobiles, la notion de filtres de réplication va être encore plus importante puisqu’elle
va permettre de filtrer au mieux les données à distribuer sur l’ensemble du parc de terminaux
mobiles. De ce fait, chaque terminal ne possèdera uniquement ses propres données. Nous verrons
d’ailleurs plus loin qu’il pourra s’avérer nécessaire de limiter la taille des bases mobiles, et donc de
filtrer les données, en raison de contraintes de volumétrie.
Il existe plusieurs types de réplication dans SQL Server, cependant seule la réplication de fusion est
prise en charge et permet de synchroniser des données entre un serveur et des terminaux portables.
Pour la mobilité, nous parlons de « web synchro » dans le sens où les PDA doivent s’appuyer sur une
DLL exposée sur un serveur web IIS pour échanger leurs données (= Agent de réplication). L’URL de
cette DLL sera donc précisée dans le code de l’application mobile.
Les synchronisations de données avec SQL Server Compact sont soumises à des règles importantes :
L’utilisation d’un serveur IIS est indispensable pour implémenter un système de

réplication entre un serveur et des terminaux mobiles (= web synchro).
Les terminaux mobiles peuvent uniquement être des subscribers (jamais des publishers,
ni des distributors).
www.wygwam.com
B. Restrictions et limitations
SQL Server Compact peut être considéré comme un système de gestion de bases de données allégé
et conçu pour les terminaux portables. Aussi, il comporte moins de fonctionnalités et présente
plusieurs limitations.
Par exemple, certaines modifications de schéma sur l’abonné sont interdites et peuvent générer des
échecs de synchronisation. Voici la liste complète des actions à ne pas entreprendre sur la base de
données abonnée :
• Supprimer ou renommer une table

• Ajouter ou supprimer une colonne dans une table
• Ajouter ou supprimer une clef primaire ou une clef étrangère
De la même façon, certaines fonctionnalités ne sont pas prises en charge par SQL Server Compact :
• Procédures stockées
• Propriétés étendues
• Vues
• Contraintes CHECK
• Fonctions utilisateurs
• Triggers
Enfin, Il est à noter que les bases SQL Compact ne peuvent pas excéder la taille de 4Go (en version
3.5).
C. Pré-requis
Voici la liste de tous les éléments nécessaires pour implémenter convenablement la réplication SQL
dans le cadre de projets mobiles :
Environnement de - .NET Framework 2.0 (ou versions ultérieures)

développement - Visual Studio 2005 (ou versions ultérieures)
- ActiveSync 4.x ou Windows Mobile Device Center (pour Vista et 7)
Serveur SQL - SQL Server 2005 ou 2008
- Composants de réplication SQL Server 2005 ou 2008
- Outils de réplication SQL Server Compact
Serveur IIS - IIS 5.x (ou versions ultérieures) installé sur même serveur ou sur un
serveur différent
- Pour IIS 7.0, il est nécessaire d’installer les composants de compatibilité
IIS 6.0
www.wygwam.com
Pour pouvoir construire un système de réplication entre des terminaux mobiles (SQL Server
Compact) et une base centrale (SQL Server), il est nécessaire d’installer les outils de réplication SQL
Server Compact.
Téléchargement des « Microsoft SQL Server Compact 3.5 Server Tools » :
http://www.microsoft.com/downloads/details.aspx?FamilyID=b18327f3-96e1-415d-b037-
9e0c46d49956&DisplayLang=en
D. Installation et déploiement sur un terminal mobile
Pour que la réplication SQL soit prise en charge par un terminal, il est question d’installer certains
composants sur le PDA. Les fichiers d’installation CAB se situent par défaut dans le répertoire
“%ProgramFiles%\Microsoft SQL Server Compact Edition\v3.5\Devices\plateforme\processeur\” :
• sqlce.type_appareil.plateforme.processeur.CAB
• sqlce.dev.langue.type_appareil.plateforme.processeur.CAB
• sqlce.repl.type_appareil.plateforme.processeur.CAB
Ces composants dépendent du type d’appareil, de plateforme et également du processeur de

l’appareil.
A noter que les bons fichiers CAB sont poussés et installés automatiquement par Visual
Studio lors du lancement d’une phase de déploiement.
www.wygwam.com
IV. Cas d’étude - Base TECHNOMADE
A. Description du projet
Dans cet article, nous allons imaginer que nous devons mettre en place un système de
synchronisation pour des techniciens nomades dont le métier est d’effectuer des interventions de
maintenance chez des clients (plomberie, électricité, etc...).
Ces techniciens possèdent chacun un terminal portable sur lequel une application mobile est
installée.
L’application mobile, développée sous Windows Mobile, doit permettre aux techniciens de
synchroniser leurs données lorsqu’ils le souhaitent en cliquant sur un simple bouton « Synchro ». Dès
lors, les techniciens doivent pouvoir recevoir les demandes d’interventions qu’ils doivent accomplir
chez les clients, et peuvent également envoyer les rapports d’interventions réalisés via le logiciel
mobile.
Cet exemple représente un cas typique d’utilisation de la réplication SQL et de l’ensemble de ses
fonctionnalités !
Ainsi, des bases de données locales, une par terminal, seront destinées à stocker le référentiel de
travail ainsi que les rapports des techniciens. Ces bases de données contenues sur les PDA
représentent donc les abonnés de la réplication de fusion. Elles pourront échanger leurs données
avec le serveur SQL lors d’un clic sur le bouton de synchronisation.
Grâce à la réplication SQL, et plus particulièrement à la construction d’un système de filtres, nous
pouvons aussi faire en sorte qu’un technicien possède dans sa base de données locale uniquement le
référentiel de travail qui lui est propre.
Ainsi la base de données d’un technicien T ne devra contenir que les demandes d’interventions qui
sont planifiées pour ce technicien (Il en est de même pour l’ensemble du référentiel, c'est-à-dire les
clients, le périmètre géographique, etc.…).
www.wygwam.com
Process :
1. La secrétaire reçoit les appels téléphoniques et saisit les demandes d’interventions des
clients via une application PC.
2. Les informations relatives aux demandes et aux clients sont alors stockées dans la base
TECHNOMADE.
3. Les agents terrain cliquent sur le bouton « Synchro » pour synchroniser leurs terminaux
mobiles.
4. Chaque technicien reçoit alors les demandes d’interventions qu’il doit réaliser.
5. Les techniciens réalisent donc les interventions et rédigent leurs rapports dans
l’application mobile.
6. Ils synchronisent de nouveau leurs terminaux pour que les rapports d’interventions
remontent dans la base serveur TECHNOMADE. (De la même façon, ils reçoivent encore
les éventuelles nouvelles demandes).
7. Une fois les rapports remontés dans la base centrale, la secrétaire peut les traiter et
envoyer les factures aux différents clients.
Ce projet est un exemple typique de l’utilisation de la réplication de fusion avec des

terminaux mobiles.
La suite de l’article s’appuiera sur cet exemple concret, afin d’exposer au mieux les concepts
importants de la construction d’un système de réplication.
www.wygwam.com
B. Description de la base TECHNOMADE
Dans ce paragraphe, nous allons décrire les tables de la base TECHNOMADE. Cette base
nous servira d’exemple pour la suite de notre article. Un script de création de base est à
votre disposition si vous souhaitez manipuler directement à partir de ce tutoriel. Cependant, il n’est
pas impératif d’utiliser cette base et de manipuler pour comprendre les grands concepts décrits dans
cet article.
La description de chacune des tables de la base TECHNOMADE est intéressante pour une meilleure
compréhension de certains conseils énoncés dans la suite de l’article. La description de chacune des
tables permet également de se rapprocher d’un exemple concret. Cependant, il n’est nullement
nécessaire de retenir le schéma de la base par cœur pour comprendre les concepts qui vont suivre.
La base TECHNOMADE contient au total 9 tables :
• TECHNICIEN: Il s’agit de la table qui permet de lister les différents techniciens nomades ainsi
que leurs identifiants et mots de passe. C’est par exemple sur cette table que sera basé
l’éventuel système d’identification dans l’application mobile.
• DEMANDE_INTERV: Il s’agit de la table qui permet de stocker les demandes d’interventions
saisies par la secrétaire suite aux appels des clients. Le champ IdTec permet de renseigner
l’identifiant du technicien qui doit réaliser la demande d’intervention en question. Le champ
IdClient est un lien direct vers le client qui a formulé la demande.
• OBJET_DEMANDE_INTERV: C’est la table qui regroupe l’ensemble des objets
d’interventions (ex: Maintenance de la chaudière, Réparation robinet, etc.…)
• CLIENT: Il s’agit de la table qui permet de stocker les informations des différents clients.
L’adresse du client peut être retrouvée grâce aux champs IdVille et IdVoie qui référencent
les tables VILLE et VOIE.
• VILLE : Stocke les différentes villes des adresses des clients
• VOIE : Stocke les différentes voies des adresses des clients
• FOURNITURE: Il s’agit de la table destinée à stocker l’ensemble des pièces et outils que vont
utiliser les techniciens durant la réalisation de leurs interventions.
• RAPPORT_INTERV: C’est dans cette table que va être stockés les différents rapports
d’interventions rédigés par les techniciens (temps de travail, signature du client, etc…)
• RAPPORT_INTERV_FOURNITURE: Cette table permettra de lister l’ensemble des pièces et
outils utilisés par un technicien durant une intervention particulière. Une fois les données de
cette table remontées, la secrétaire pourra par exemple modifier les différents stocks de
fournitures, et ainsi mettre à jour la table FOURNITURE.
www.wygwam.com
Nous pouvons distinguer 2 groupes de tables :
• Le référentiel de travail. Il s’agit des tables qui contiennent les données de travail du
technicien. C’est sur ces tables que l’application mobile effectuera des requêtes SELECT pour
extraire des informations précises. Les données de ces tables ne seront jamais modifiées sur
le terrain. Tables : TECHNICIEN, DEMANDE_INTERV, OBJET_DEMANDE_INTERV, CLIENT,
FOURNITURE, VILLE, VOIE.
• Les tables d’exports. Ce sont les tables destinées à stocker les données saisies sur le terrain.
Contrairement aux tables du référentiel, des ordres INSERT, UPDATE et DELETE peuvent
être exécutés par l’application mobile. Il s’agit des tables RAPPORT_INTERV et
RAPPORT_INTERV_FOURNITURE.
Il s’agit bien sûr d’une base exemple qui va permettre de construire un simple système de
réplication. Pour ne pas compliquer les choses, et pour pouvoir nous concentrer sur un
exemple simple, les tables ne possèdent que des PK en guise de contraintes. De la même façon, la
base TECHNOMADE ne respecte peut-être pas certaines normes habituelles de conception. Mais peu
importe, l’essentiel est de comprendre la mise en place de la réplication…
www.wygwam.com
C. Installation de la base TECHNOMADE
Le script de création de la base de données TECHNOMADE, que nous utilisons dans cet
article, est téléchargeable à partir du lien ci-dessous. Pour pouvoir manipuler, il faut dans un
premier temps exécuter ce script dans SQL Server Management Studio.
Lien de téléchargement du script de création de la base TECHNOMADE :
http://www.pierre-cambier.fr/scriptCreateTechnomade.sql
www.wygwam.com
V. Configuration du Distributor
Pour implémenter un système de réplication, il est important dans un premier temps de configurer la
base de distribution. Cette configuration doit normalement s’effectuer une seule fois.
Procédure :
Il faut dans un premier temps cliquer-droit sur le nœud « Replication » et choisir l’option
« Configure Distribution… » :
Cliquez sur « Next » sur le premier écran du wizard :
www.wygwam.com
Sur l’écran suivant, vous allez préciser que le distributor utilisera la même instance SQL Server que la
base publiée. Cochez la première option et cliquez sur « Next »:
L’écran suivant vous demande de saisir le chemin vers le répertoire des snapshots :
www.wygwam.com
Comme la réplication est de type « web synchro » et utilise un serveur IIS pour assurer
l’échange des données, il est nécessaire de stocker les snapshots dans un répertoire
accessible à la fois par le serveur IIS et par l’agent de snapshots situé sur le serveur. Il est donc
important de créer au préalablement un répertoire partagé et de spécifier son chemin réseau (ex :
\\NOM_MACHINE\rep).
Créez donc un répertoire nommé « repldata » à la racine de C: par exemple :
Partagez ce répertoire en y attribuant les droits nécessaires pour autoriser l’accès à SQL Server mais
également au serveur IIS :
www.wygwam.com
Une fois le répertoire créé et paramétré, notez son chemin d’accès réseau :
www.wygwam.com
Inscrivez ensuite ce path dans la nouvelle fenêtre du wizard SQL Server, puis cliquez sur « Next »:
L’écran suivant permet de préciser le nom et le path de la base de distribution. Laissez les
paramètres par défaut et cliquez sur le bouton « Next »:
www.wygwam.com
Cet écran permet d’activer la base de distribution. Ne modifiez rien et cliquez sur le bouton « Next »:
Sur l’écran suivant, vous pouvez sélectionner la deuxième option si vous souhaitez générer un script
de configuration du Distributor. Cliquez sur « Next »:
www.wygwam.com
Enfin, ce dernier écran permet de récapituler les différentes actions qui vont être entreprises par SQL
Server. Pour lancer réellement la configuration du distributor, cliquez sur le bouton « Finish »:
www.wygwam.com
Une fois le processus achevé, vous pouvez remarquer la présence d’une base nommée
« distribution » dans le nœud « System Databases »:
Si vous souhaitez maintenant modifier les propriétés de la distribution, vous pouvez

cliquer droit sur le nœud « Replication » et sélectionner « Distributor Properties… ».
www.wygwam.com
VI. Configuration des publications
A. Notion de publication
Une publication est rattachée à une et une seule base publisher.
La publication permet de définir l’ensemble des éléments suivants :
• Articles : Ce sont les tables et les colonnes répliquées

• Filtres : La publication peut se baser sur un système de filtres pour restreindre le nombre de
données sur chacun des abonnés
• Options: De nombreuses options peuvent être liées à une publication particulière et
permettent de définir le comportement des synchronisations.
Plusieurs publications peuvent être rattachées à une même base.
Si le modèle de données le permet, nous pouvons par exemple distinguer les tables du
référentiel de travail de celles qui correspondent aux tables destinées à stocker les données
collectées sur le terrain par les différents terminaux.
Dans notre exemple, il est astucieux d’implémenter 2 publications différentes. La première

permettra de répliquer les tables du référentiel de travail (tables dont les données doivent
uniquement descendre sur les PDA), tandis que l’autre publication va être utilisée pour la
remontée des données terrain. Ces 2 publications implémentées ne possèderont pas les mêmes
options, et seront configurées selon le sens des flux (descendant ou remontant).
Le fait de séparer les tables du référentiel de celles des données terrain en 2 publications
différentes permet d’éviter les conflits.
Autre avantage : dans le code .NET de l’application mobile, il sera possible de lancer la synchro du
référentiel ou celle des exports terrain indépendamment et à différents endroits de l’application
(selon les besoins métiers).
B. Création d’une nouvelle publication via le wizard
Une publication peut se créer via un wizard ou via un script. Dans l’exemple ci-dessous, nous
utiliserons le wizard pour créer la publication.
Pour créer une nouvelle publication, il est nécessaire de déployer le nœud « Replication », de cliquer
droit sur « Local Publications » et de choisir l’option « New Publication… »:
www.wygwam.com
S’en suivront alors une série d’écrans permettant de sélectionner les articles, de définir les filtres et
autres options de la réplication.
Procédure :
Sur le premier écran du wizard, cliquez directement sur « Next ».
Sur le second écran, vous devez sélectionner la base à répliquer (publisher). Sélectionnez donc
« TECHNOMADE » et cliquez ensuite sur « Next » :
www.wygwam.com
Ensuite, sélectionnez « merge replication » et cliquez sur « Next ». Pour rappel la « merge
replication » est le seul type de réplication pris en charge par SQL Server Compact :
Sur l’écran suivant, décochez « SQL Server 2008 » et cochez l’option « SQL Server 2005 Mobile,
SQL Server Compact 3.1 and higher » :
En validant ce dernier écran en cliquant sur « Next », vous arriverez sur l’écran du choix des articles.
www.wygwam.com
C. Définition des articles
Les articles ne sont autres que l’ensemble des tables et colonnes qui vont être répliquées sous
l’utilisation d’une publication.
L’écran « Articles » représente la liste des articles définis pour la publication.
L’écran permet d’ajouter ou de supprimer facilement des tables à répliquer en les cochant ou
décochant dans la liste.
Chacune des tables est représentée sous la forme d’un nœud, qui une fois déployé, permet
également de cocher ou de décocher les colonnes répliquées :
Dans cet exemple, nous allons considérer que toutes les tables sont représentatives du
référentiel de travail sauf RAPPORT_INTERVENTION et
RAPPORT_INTERVENTION_FOURNITURE. Ces dernières seront destinées à recevoir les rapports
d’interventions et seront mises à jour uniquement à partir du terrain par les utilisateurs nomades.
De cette manière, et conformément à ce qui a été expliqué précédemment, il est habile de créer une
première publication regroupant tous les articles sauf RAPPORT_INTERVENTION et
RAPPORT_INTERVENTION_FOURNITURE. Une seconde publication, devra donc être créée pour la
remontée des informations terrain et devra contenir les 2 tables précédemment citées. On sépare
ainsi la synchronisation du référentiel de travail de celle des informations saisies sur le terrain en 2
publications différentes.
www.wygwam.com
Pour créer la publication liée au référentiel, nous allons donc sélectionner l’ensemble des tables
excepté les tables d’export :
A noter que l’option « Show only checked articles in the list » permet de ne visualiser que
les articles sélectionnés dans la liste.
www.wygwam.com
Des propriétés supplémentaires peuvent également être définies sur chacun des articles.
Le bouton « Article Properties » permet d’afficher une fenêtre permettant de définir les options des
articles. Ces propriétés peuvent être saisies pour des articles particuliers, ou pour l’ensemble des
articles sélectionnés (option « Set properties for all table articles ») :
Sur l’écran ci-dessus, notez l’existence d’un onglet « Resolver » sur lequel nous allons revenir
plus loin dans cet article.
Le premier groupe de paramètres permet de définir les objets copiés sur l’abonné par le processus
de réplication (indexes, clefs, contraintes…).
Le second groupe, quant à lui, est le plus important car il définit des propriétés concernant le
comportement des tables répliquées.
La propriété importante, qu’il est nécessaire de faire attention, est la « Synchronization direction ».
En effet, cette option permet de préciser si les données d’une table seront répliquées d’une manière
bidirectionnelle ou uniquement dans le sens « Serveur vers Abonné ».
www.wygwam.com
Le fait de définir l’ensemble des tables du référentiel en « Download only » permet

d’optimiser les processus de réplication et permet également d’éviter les modifications
anormales des abonnés.
Il est évident que seules les tables du référentiel, autrement dit, les tables dont les données ne
sont jamais modifiées sur le terrain, doivent être définies en « Download only ».
Les autres tables, destinées à stocker les données terrain, sont définies en « Bidirectionnal ».
(L’option « Upload only » n’existe pas).
Pour la mise en place de notre publication, nous allons donc modifier l’option « Synchronization
direction » pour choisir « Download only to Subscriber, prohibit Subscriber changes » :
En validant l’option « Download-only » en cliquant sur le bouton « OK », les petites icones qui
symbolisent les articles sélectionnés dans la liste seront grisées. De la même façon, l’option
« Highlighted table is download only » sera cochée et l’intitulé « For this table, only changes
made at the Publisher or a server subscription are replicated » sera visible :
www.wygwam.com
Nous venons ainsi de définir l’ensemble des articles liés à la publication du référentiel de travail.
Pour la seconde publication, c’est à dire celle qui permettra de remonter les informations saisies sur
le terrain, il sera nécessaire de cocher les tables RAPPORT_INTERVENTION et
RAPPORT_INTERVENTION_FOURNITURE et de ne pas modifier les propriétés afin de les laisser en
mode « Bidirectionnal ». Le fait de déclarer ces 2 articles en « Download only » rendrait bien
évidemment la remontée des saisies terrain impossible.
La sélection et la définition des articles prennent fin en cliquant sur le bouton « Next ».
L’écran suivant vous avertira que la réplication SQL va créer une colonne supplémentaire sur chacun
des articles sélectionnés. Cette colonne de type « Unique identifier » est essentielle au bon
fonctionnement de la réplication, et permettra au moteur de réplication de tracer l’ensemble des
modifications sur les tables à répliquer. Sans cette colonne, les synchronisations différentielles de
données seraient donc impossibles.
En cliquant sur le bouton « Next », vous passerez directement à la définition des filtres…
www.wygwam.com
D. Définition d’un système de filtres
Un système complet de filtres peut être mis en place sur une publication particulière afin de
restreindre et de limiter le nombre de données sur chacun des abonnés :
Les filtres ont un rôle important pour la réplication dans le sens où ils permettent de filtrer
l’ensemble des données qui descendent sur les terminaux mobiles.
En effet, tous les terminaux ne doivent pas forcément posséder les mêmes données dans leur base
locale. Dans notre exemple de la base TECHNOMADE, chaque terminal est affecté à technicien
spécifique. Un technicien T1 ne doit pas avoir le même référentiel de travail que le technicien T2.
En effet, les interventions que doit réaliser le technicien T1 ne seront pas les mêmes que celles
affectées au technicien T2. Il en est de même pour les clients, les objets des demandes, etc.…
Pour certains projets mobiles, l’implémentation de filtres peut avoir un rôle important pour la
sécurité des données. En effet, les filtres peuvent être parfois un bon moyen de restreindre la
visibilité des données protégées par des droits.
Enfin, implémenter un système de filtres est essentiel quant à la volumétrie des bases mobiles.
S’ils n’existaient pas, les bases mobiles répliquées pourraient être trop volumineuses et ne
pourraient même peut-être pas être prises en charge (limite physique à 4Go pour une base mobile
SQL Server Compact 3.5).
www.wygwam.com
Dans le cadre de notre article, nous allons donc nous baser sur la notion de techniciens pour
construire un système de filtres. (Il aurait été aussi possible de définir qu’un terminal n’est pas
rattaché à un technicien spécifique mais à un périmètre géographique).
Il existe 2 types de filtres :
• Les filtres classiques (où tous les articles sont au même niveau)
• Les filtres « join » (arborescence)
Les filtres « join » permettent de former une arborescence d’articles de la publication.
Le système de filtre peut donc être représenté sous la forme d’un arbre composé de nœuds et de
feuilles.
Les tables sont reliées entre elles à l’aide de jointures SQL.
Les filtres « join » définissent le fait que les données d’une table dépendent des données filtrées de
la table parent, qui dépendent des données filtrées de la table parent et ainsi de suite…
Il s’agit donc d’un système de filtrage complexe, précis et très logiquement lié au fonctionnel
attendu. En effet, le système de filtres s’établit en adéquation avec les besoins et le fonctionnel de
l’application mobile.
Le point d’entrée du système n’est autre que la table située en haut de l’arborescence.
Dans notre exemple TECHNOMADE, nous allons considérer qu’un terminal est attribué à un et un
seul technicien spécifique. Nous allons donc nous baser sur la table TECHNICIEN, et plus
particulièrement sur le champ IdTec, pour initialiser le système de filtres.
Pour ajouter le premier filtre de la publication, il faut cliquer sur le bouton « Add » puis sélectionner
« Add filter… » :
www.wygwam.com
Sur l’écran suivant, nous allons sélectionner l’article TECHNICIEN dans le menu déroulant du haut,
puis saisir le filtre « WHERE [IdTec] = HOST_NAME() » dans le champ de saisie de droite et cliquer
sur « OK » :
Filtre d’entrée : WHERE [IdTec] = HOST_NAME()
HOST_NAME() n’est autre qu’une fonction qui permet de récupérer le nom de la machine.
Elle va nous servir ici pour initialiser le filtrage des données. Dans notre cas, cette fonction
doit retourner l’identifiant du technicien.
L’association du « hostname » et de l’identifiant du technicien, sera effectuée dans le code de

l’application mobile. La valeur retournée par la fonction HOST_NAME() sera utilisée lorsque le PDA
initialisera sa phase de réplication.
Dès lors, lorsqu’un terminal se connecte au serveur SQL, il est immédiatement reconnu et le
système de filtres peut ainsi déterminer l’ensemble des données qui doivent être affectées au
technicien en question (en fonction de l’id retourné par la fonction HOST_NAME()).
(Nous verrons par la suite comment déclarer cette variable au niveau du code .NET de l’application
mobile).
www.wygwam.com
Nous allons à présent rajouter un filtre de type « join » qui sera lié au filtre de l’article
TECHNICIEN que nous venons de créer. De cette manière, nous allons spécifier que les lignes des
demandes d’interventions doivent être liées à un technicien spécifique.
Pour effectuer cette action, sélectionnez le filtre précédemment créé dans la zone de gauche, cliquez
sur le bouton « Add », puis sélectionnez « Add Join to Extend the Selected Filter… » :
Dans l’écran qui apparaitra, il sera question de renseigner les éléments de la jointure. Sélectionnez
donc la table DEMANDE_INTERV dans la liste déroulante de droite, puis sélectionnez les colonnes
IdTec pour les 2 tables sur lesquelles va s’effectuer la jointure :
www.wygwam.com
En cliquant sur « OK », vous validerez le fait qu’une ligne de demandes d’interventions sera
distribuée au technicien concerné par cette intervention.
De retour sur l’écran précédent, remarquez que l’arborescence des filtres est en train de se former :
De la même façon, nous allons maintenant spécifier que seuls les clients rattachés aux demandes
d’interventions filtrées seront descendus sur le terminal du technicien.
Pour cela, positionnez-vous sur le filtre DEMANDE_INTERV et sélectionnez de nouveau « Add Join
to Extend the Selected Filter… ». Sur l’écran ci-dessous, choisissez la table CLIENT dans le menu
déroulant de droite, puis sélectionnez les colonnes IdClient pour effectuer la jointure. Cliquez sur
« OK » pour valider ce nouveau filtre :
www.wygwam.com
De retour sur l’arbre des filtres, effectuez encore une fois la même opération pour les tables VILLE et
VOIE à partir du nœud CLIENT de l’arborescence :
www.wygwam.com
Enfin, nous allons poser un dernier filtre pour les objets des demandes d’intervention, à partir du
nœud DEMANDE_INTERV :
www.wygwam.com
Au final, l’arborescence des filtres doit être similaire à l’arborescence ci-dessous :
Nous allons considérer que les fournitures ne sont pas liées à des techniciens particuliers. En
effet, tous les techniciens peuvent utiliser toutes les fournitures. C’est pourquoi, nous n’allons
pas définir de filtres sur la table FOURNITURE.
Interprétation des filtres créés et process :
• Un terminal se connecte au serveur et initialise une synchronisation en exposant l’identifiant

du technicien dans la fonction HOST_NAME(). Exemple : HOST_NAME() = « JDU » qui est
l’identifiant de l’agent Jean Dupont.
• Dès lors, Jean Dupont recevra uniquement les demandes d’interventions qui lui sont
attribuées. (WHERE TECHNICIEN.IdTec = DEMANDE_INTERV.IdTec)
• De la même manière, il recevra uniquement les informations des clients qui concernent ses
interventions (WHERE DEMANDE_INTERV.IdClient = CLIENT.IdClient)
Et ainsi de suite pour les villes et les voies…
www.wygwam.com
La complexité de l’arborescence des filtres peut être un inconvénient au niveau des

performances des synchronisations. Plus le système est complexe, plus les calculs liés à la
phase d’initialisation des synchronisations seront longs.
Tous les articles n’ont pas la nécessité d’être filtrés (cas de la table FOURNITURE par
exemple). En effet, pour des raisons de performance, il est conseillé de ne pas filtrer les
tables non-volumineuses.
En ce qui concerne la remontée des rapports d’interventions (2ème publication), nous

pouvons spécifier un filtre du type WHERE 0 = 1 si on souhaite purger automatiquement
les données remontées sur la base SQL Compact du terminal. Les tables d’exportation étant
définies en « Bidirectionnal», l’application du filtre WHERE 0 = 1 aura pour effet de supprimer les
données sur les bases locales. Pour les articles « Bidirectionnal », l’upload des données a lieu
avant le download.
Cliquez sur le bouton « Next » pour valider le système de filtres que vous avez créé.
E. Propriétés de l’agent de snapshots
Il s’agit de la dernière étape de configuration de la publication. Il est ici question de préciser si la

publication va générer automatiquement son snapshot principal lors de sa création, et surtout à
quelle fréquence il sera automatiquement rafraichi.
www.wygwam.com
A noter que le rafraichissement périodique et automatique du snapshot permet au moteur de

réplication de mettre à jour les métadonnées ainsi que le schéma de la base répliquée.
Cliquez sur le bouton « Next » pour accéder au prochain écran :
Cet écran permet de définir le compte qui sera utilisé par l’agent de snapshots.
Cliquez sur « Security Settings » et choisissez de faire tourner l’agent de snapshot sous le compte de
service de l’agent SQL :
www.wygwam.com
A noter que vous pouvez très bien créer un nouveau compte de service qui sera utilisé par l’agent de
snapshot. Dans tous les cas, le compte utilisé doit avoir des accès en écriture et en lecture sur le
répertoire partagé des snapshots précédemment créé.
Validez l’utilisation du compte en cliquant sur « OK », puis passez à l’écran suivant en cliquant sur le
bouton « Next ».
F. Fin de la création de la publication
Nous nous approchons de la fin de la création de la publication.
Sur l’écran ci-dessous, vous pouvez choisir de générer un script de création de la publication en
sélectionnant la deuxième option. Dans tous les cas, cliquez sur « Next » pour passer à l’écran
suivant :
L’écran suivant permet de récapituler les actions qui vont être entreprises lors de la création de la
publication. Vous devez également spécifier ici le nom de votre publication :
www.wygwam.com
Nommez votre publication « PubRef » et cliquez sur « Finish » pour achever la création :
Une fois la publication générée, vous la verrez apparaitre sous le nœud « Local Publications ».
www.wygwam.com
Reprenez l’ensemble de ces étapes (de la définition des articles jusqu’à ce paragraphe) pour
créer la publication « PubUp » qui sera utilisée pour la remontée des rapports
d’interventions. Les articles RAPPORT_INTERVENTION et RAPPORT_INTERVENTION_FOURNITURE
devront être définis en « Bidirectionnal »
G. Génération du snapshot principal
Dans le paragraphe précédent, nous avons donc créé les 2 publications sur la base TECHNOMADE.
Ces 2 publications sont normalement visibles sous le nœud « Local Publications » :
Pour pouvoir à présent utiliser les publications, il est nécessaire de générer un premier snapshot
pour chacune d’elles.
www.wygwam.com
Pour rappel, le snapshot est un ensemble de métadonnées qui comporte entre autre le schéma de la
base. Ces métadonnées seront sollicitées lors de la première synchronisation d’un terminal, c’est à
dire lors de la création de la base mobile.
Le snapshot principal est créé automatiquement si l’option « Create a snapshot immediately » est
cochée dans le wizard lors de la création de la publication ; si ce n’est pas le cas, il est possible de le
générer manuellement.
Pour générer le snapshot principal, cliquez-droit sur une publication précédemment créée et
choisissez « View Snapshot Agent Status » :
Sur la fenêtre suivante, cliquez sur « Start » et patientez le temps que le snapshot se génère :
www.wygwam.com
Faites cela pour les 2 publications.
La génération du snapshot principal crée automatiquement des indexes et des triggers sur
les tables répliquées. C’est également la génération du snapshot qui entraine la création
des colonnes « rowguid » (uniqueidentifier) sur chacun des articles. Il se peut donc que la
génération du snapshot principal engendre une forte fragmentation des indexes déjà posés sur les
tables de la base.
La génération du snapshot génère une erreur si le compte de l’agent de snapshot n’a pas
les droits d’accès au répertoire partagé.
H. Modification une publication
Lorsqu’une publication est posée, il est toujours possible de modifier ses propriétés.
Pour modifier les propriétés d’une publication, vous devez cliquer-droit dessus et sélectionner
« Properties »:
www.wygwam.com
Dès lors, vous serez en présence d’une nouvelle fenêtre, découpée en plusieurs pages, qui vous
permettra de modifier l’ensemble des propriétés de la publication implémentée :
La page « Articles » permet par exemple de modifier la liste des articles associés à la publication.
Vous pouvez ainsi ajouter ou supprimer des articles, ou modifier leurs propriétés. La page « Filters
rows » fait référence au système de filtres mis en place sur la publication :
www.wygwam.com
www.wygwam.com
Il est important de savoir que suite à certaines modifications sur une publication
(modification sur les filtres, les articles, etc.…), les abonnements peuvent devenir
obsolètes. Les abonnements devront alors être réinitialisés (Cf. plus loin).
I. Suppression d’une publication
Pour continuer à suivre ce tutoriel en manipulant, ne supprimez pas les publications comme
expliqué ci-dessous.
Pour supprimer une publication posée sur la base de données, il suffit de cliquer-droit dessus puis de
sélectionner « Delete » :
Si de nombreuses partitions sont définies, il se peut que la suppression d’une publication

prenne du temps (voire n’aboutit pas). En effet, le fait de supprimer de nombreuses
partitions génère une écriture de logs en masse.
Pour lever ce problème, 2 solutions :
• Supprimer unes à unes les partitions définies sur la publication, avant de détruire la
publication proprement dite.
• Utiliser la procédure stockée « sp_removedbreplication » qui permet de forcer la
suppression des publications sur une base sans générer de logs.
www.wygwam.com
VII. Propriétés avancées des publications
Dans le chapitre précédent, nous avons construit 2 publications sur la base TECHNOMADE. Il est à
noter que d’autres propriétés importantes peuvent être configurées.
Pour accéder à ces propriétés, cliquez-droit sur une publication et sélectionner « Properties » :
A. Modification du répertoire de snapshots
La page « Snapshot » présent dans les propriétés de la publication permet de spécifier le répertoire
partagé des snapshots :
www.wygwam.com
En cochant la case « Put files in the following folder », vous pouvez spécifier un chemin différent,
autre que celui par défaut, pour le stockage des snapshots.
Pour rappel, le répertoire spécifié devra être un répertoire réseau partagé et accessible par SQL
Server et par IIS (définition des droits adéquats).
Il est à noter que la volumétrie de ces snapshots peut considérablement augmenter. En

effet, la taille de ce répertoire est proportionnelle au nombre de partitions déclarées.
Aussi, il peut s’avérer pratique de savoir comment spécifier un nouveau répertoire (sur un autre
disque par exemple), dans le cas où la volumétrie des métadonnées deviendrait problématique.
B. Définition de la période de rétention
La période de rétention correspond à un délai durant lequel les métadonnées liées aux
synchronisations sont stockées et historisées dans des tables systèmes.
Une fois la période de rétention dépassée, les données sont purgées et les abonnements liés à la
publication deviennent obsolètes et doivent être réinitialisés (Cf. plus loin).
Aussi, pour éviter d’effectuer une réinitialisation, chaque terminal doit répliquer au moins une fois
pendant le délai de rétention. Si un PDA ne réplique pas au moins une fois durant cette période, la
réinitialisation de son abonnement (base locale) sera inévitable.
La période de rétention doit être paramétrée de manière habile, selon les besoins
métiers :
• Si la période de rétention est trop courte, les terminaux sur le terrain risquent de devoir
souvent réinitialiser leurs abonnements (très couteux).
• Si la période de rétention est trop longue, la volumétrie des métadonnées stockées en
tables systèmes deviendrait alors trop importante et risquerait de fortement réduire les
performances.
La configuration de la période de rétention est possible sur la page « General » des propriétés de la
publication :
www.wygwam.com
Sur cette page, il est possible de définir proprement cette période de rétention (par défaut : 14
jours). Nous avons également la possibilité de cocher la case « Subscriptions never expire » si les
synchronisations s’effectuent de manière occasionnelle et si elles ne sont pas volumineuses en
termes de données échangées. Dans ce cas, les abonnements ne deviendront jamais obsolètes et les
terminaux mobiles ne devront jamais effectuer de réinitialisation.
C. Options des abonnements
Les propriétés liées au comportement des abonnements d’une publication sont situées dans l’onglet
« Subscription Options » dans les propriétés de la publication :
www.wygwam.com
J’attire votre attention sur les propriétés de filtres :
• « Validate Subscribers » permet de définir le nom de la fonction HOST_NAME() (Cf. chapitre

VI.D.)
• « Precompute partitions » joue un rôle très important au niveau du comportement et des
performances des synchronisations (Cf. le chapitre XIII.B. de cet article)
D. Notions de partitions
L’onglet « Data Partitions » des propriétés de la publication permet de définir l’ensemble des
partitions :
www.wygwam.com
La notion de partitions est directement liée à l’option « Precompute partitions » de l’onglet

« Subscription Options ». La définition de plusieurs partitions n’est possible que lorsque la valeur de
l’option « Precompute partitions » est « true ».
Nous reviendrons sur l’option « Precompute partitions » plus tard dans cet article.
L’utilisation des partitions et de l’option « Precompute partitions » joue un rôle

important pour les performances du système de réplication.
Il existe une partition pour chaque terminal, donc pour chaque abonnement. Une partition permet
de structurer un snapshot particulier pour chacun des abonnés.
Il s’agit d’un découpage habile permettant d’optimiser les réplications de chaque terminal.
Une partition est définie à l’aide du HOST_NAME(). Pour rappel, le HOST_NAME() correspond à la
fonction dont la valeur permet d’initialiser le système de filtres. (Point d’entrée de l’arborescence des
filtres).
Dans le cadre de notre exemple, nous avons défini que chaque terminal est attribué à un et un seul
technicien. Nous allons donc entrer les différents HOST_NAME() qui correspondent aux différents
identifiants des techniciens.
www.wygwam.com
Pour effectuer cette action, cliquez sur le bouton « Add ».
Sur ce nouvel écran, il est question de renseigner la valeur du HOST_NAME() de l’abonné, ainsi que
la période de renouvellement automatique du snapshot. Entrez donc l’identifiant du technicien Jean
Dupont (JDU) :
La partition « JDU » contiendra donc les métadonnées utilisées par le terminal qui n’aura que les
demandes d’interventions et les clients de Jean Dupont.
Cliquez sur le bouton « OK » pour revenir sur l’écran précédent et voir apparaitre la partition dans la
liste :
www.wygwam.com
Recommencez la même opération en créant une partition pour les 3 autres techniciens. Identifiants :
FLE, MDU et PMA :
Un snapshot particulier sera donc créé pour chacun des abonnés. Pour générer immédiatement le
snapshot, il faut sélectionner la partition puis cliquer sur le lien « Generate the selected snapshots
now ».
Lorsque la case « Automatically define a partition… (…) » est cochée, le système est capable de
créer automatiquement une partition (= abonné) et de générer automatiquement son snapshot et
cela lorsqu’un terminal se connecte avec un HOST_NAME() qui n’est pas encore connu en partitions.
www.wygwam.com
Le fait de cocher la case « Automatically define a partition… (…) » permet donc de

générer automatiquement les partitions à chaque fois qu’un terminal effectue sa première
synchronisation.
Cela évite donc à l’administrateur de saisir manuellement chacune des partitions pour les
différents PDA du parc. Cependant, il faut savoir que lorsqu’une partition est créée
automatiquement, son snapshot se génère et l’utilisateur du terminal est contraint de patienter un
peu plus longtemps le temps que cette phase se déroule entièrement.
www.wygwam.com
VIII. Configuration de la synchronisation web
Nous allons maintenant configurer et tester la synchronisation web afin de pouvoir utiliser les
publications créées, à partir d’un terminal mobile.
Le terminal mobile devra se connecter à une DLL exposée par le serveur web IIS (via GPRS, Wifi ou
sur station d’accueil) pour pouvoir utiliser la réplication.
A. Configuration de IIS
Procédure :
Pour configurer la synchronisation web, vous devez cliquer-droit sur une publication et sélectionner
« Configure Web Synchronization » :
Pour les utilisateurs de Windows Vista ou Windows 7 :

Il est d’abord important de vérifier que les outils de compatibilité IIS 6 sont installés sur le
système. Pour cela allez dans le panneau de configuration, puis « programmes » puis vérifiez que
les outils de compatibilités sont bien cochés dans les fonctionnalités Windows.
www.wygwam.com
www.wygwam.com
Pour les utilisateurs de Windows 7 :

La configuration de la synchronisation web à partir de SQL Management Studio peut
générer un bug et afficher ce genre de message d’erreur :
Pour remédier à ce problème, il est nécessaire de lancer le wizard de configuration à partir de

l’exécutable « ConnWiz » situé par défaut dans le répertoire « \Program Files\Microsoft SQL
Server Compact Edition\v3.5\Tools » :
www.wygwam.com
Une fois le wizard lancé, cliquez sur le bouton « Next » dès le premier écran « Welcome (…) ».
Sur l’écran suivant, choisissez le type de subscriber « SQL Server Compact », et cliquez sur « Next »:
L’écran suivant permet de configurer le répertoire virtuel de IIS sur lequel va être exposé la DLL qui
correspond à l’agent de réplication. Dans le premier champ de texte, laissez le nom de l’ordinateur
par défaut. Choisissez « Create a new virtual directory » puis déployez les différents nœuds pour
sélectionner « Default Web Site » et cliquez sur « Next » :
www.wygwam.com
Sur l’écran qui suit, entrez le nom « webSync » pour l’alias (il s’agira du nom du répertoire virtuel qui
sera utilisé dans l’URL de la réplication web). Vous devez également spécifier le chemin du répertoire
physique qui va contenir la DLL utilisée pour la réplication web. (L’alias pointera alors sur ce
répertoire physique) :
Cliquez sur le bouton « Next » puis validez que le répertoire sera automatiquement créé :
De la même façon, validez que vous souhaitez copier automatiquement l’agent de réplication (DLL)
dans le répertoire physique spécifié :
www.wygwam.com
Ensuite, vous serez obligé de choisir de ne pas utiliser de connexions sécurisées HTTPS. Cliquez sur
« Next » :
Sur l’écran suivant, spécifiez que les terminaux devront utiliser un login et un mot de passe pour se
connecter au serveur IIS. Cochez la deuxième option, puis cliquez sur « Next » :
www.wygwam.com
Sur le prochain écran, laissez cocher la case « Integrated Windows authentication » puis cliquez
sur « Next » :
L’écran ci-dessous permet d’ajouter les comptes utilisateurs qui pourront accéder au répertoire
virtuel que vous venez de créer. Cliquez sur « Add » pour spécifier un compte utilisateur :
www.wygwam.com
Saisissez le compte Windows qui va accéder au répertoire virtuel puis cliquez sur « OK » :
De retour sur l’écran précédent, cliquez sur « Next » pour continuer :
www.wygwam.com
L’écran ci-dessous permet de préciser le répertoire des snapshots qui devra être accessible par IIS.
Saisissez le chemin réseau puis cliquez sur « Next » :
Enfin, cet écran récapitule l’ensemble des actions qui vont être entreprises. Notez que le système va
créer les répertoires adéquats (physique et virtuel), qu’il va copier l’agent de réplication
« sqlcesa35.dll » dans le répertoire physique, etc.… Cliquez sur « Finish » pour lancer la
configuration !
www.wygwam.com
Une fois la configuration achevée, cliquez sur « Close » :
B. Test de la synchro web
Nous allons maintenant tester que la configuration de la synchronisation web s’est correctement
déroulée; et surtout que la DLL de réplication est bien accessible !
Entrez l’URL suivante dans un navigateur web (Internet Explorer par exemple) :
http://localhost/webSync/sqlcesa35.dll et visualisez le résultat :
www.wygwam.com
Si vous n’obtenez pas le message « Microsoft SQL Server Compact Server Agent », il s’agit peut-être
d’un problème de droits.
Dans ce cas, vérifiez que le compte Windows utilisé possède bien les droits d’accès au répertoire
virtuel « webSync » ainsi qu’à la DLL « sqlcesa35.dll » :
Pour cela, allez dans les outils d’administration, et plus particulièrement dans la gestion de
l’ordinateur :
Dans la gestion de l’ordinateur, déployer le nœud « Services et applications » puis sélectionnez

« Internet Information Services » dans la partie gauche de l’écran.
Ensuite, dans le cadre de droite, déployez les nœuds « Sites » et « Default Web Site » pour pouvoir
sélectionner le répertoire virtuel « webSync ».
Cliquez-droit dessus puis choisissez d’éditer les permissions. Dans l’onglet « Sécurité » de la nouvelle
fenêtre, vérifiez que le compte Windows a les droits d’accès nécessaires au répertoire virtuel :
www.wygwam.com
Si c’est OK, nous allons passer directement au test de la publication créée.
Nous allons effectuer une première réplication de données à l’aide de SQL Server Management
Studio (et non à partir du code .NET d’une application mobile pour le moment).
Procédure :
Commencez par ouvrir une nouvelle instance de SQL Server Management Studio en spécifiant le type
de serveur « SQL Server Compact Edition » et en saisissant une nouvelle base de données mobile
(test.sdf) (Vous devez sélectionner « Add new database » dans la liste déroulante). Cliquez ensuite
sur « Connect » :
www.wygwam.com
Une fois connecté, déployez le nœud « Replication » puis cliquez-droit sur « Subscriptions » et
sélectionnez « New Subscriptions » :
Cliquez directement sur « Next » sur le premier écran du wizard « Welcome (…) ».
L’écran suivant permet de rechercher un Publisher et une publication particulière. Cliquez sur la liste
déroulante et sélectionnez « Find SQL Server Publisher ». Connectez-vous à votre instance SQL sur
laquelle se trouve le Publisher, puis sélectionnez la publication « PubRef » implémentée sur la base
TECHNOMADE, puis cliquez sur « Next » :
www.wygwam.com
www.wygwam.com
Sur l’écran suivant, vous devez spécifier le nom de l’abonnement ainsi que le HOST_NAME() qui va
être utilisé pour initialiser la partition et le système de filtres.
Pour le moment, nous allons répliquer une base mobile spécifique pour le technicien Jean Dupont !
Entrez donc l’identifiant JDU dans les 2 champs de saisie, puis cliquez sur « Next » :
Le nom de l’abonnement (« Subscription name ») est obligatoire mais n’est pas utilisé par le
paramétrage de la publication. Il est souvent coutume de le renseigner avec la même valeur que celle
du HOST_NAME().
Sur l’écran suivant, vous allez spécifiez dans le premier champ de saisie, l’URL utilisée pour la
synchronisation web.
Choisissez ensuite l’option « The Subscriber will be authenticated » et précisez le nom d’utilisateur
ainsi que le mot de passe du compte Windows qui va être utilisé pour accéder au répertoire virtuel.
Cliquez ensuite sur « Next » :
www.wygwam.com
Sur l’écran ci-dessous, vous allez préciser que le type de connexion au serveur SQL sera « Windows
Authentication ». Ainsi, l’agent de réplication n’utilisera pas de compte utilisateur SQL spécifique
pour atteindre la base de données. Laissez donc la première option cochée puis cliquez sur « Next » :
www.wygwam.com
Enfin l’écran suivant récapitule les différents paramètres de l’abonnement que vous allez créer pour
le technicien Jean Dupont (JDU). Cliquez sur « Finish » pour lancer votre première réplication de
données !!
Notez que sur cet écran figurent des portions de code C# et Visual Basic qui peuvent
facilement être récupérées et qui permettent de lancer la réplication avec le même
paramétrage au sein d’une application mobile (Nous reviendrons plus en détail sur le code .NET
dans le prochain chapitre).
www.wygwam.com
Ca y est ! Vous venez non seulement de tester la configuration web mais vous venez également
d’effectuer une première réplication de données s’appuyant sur la publication « PubRef » !
Cliquez sur le bouton « Close » de la fenêtre, puis déployez le nœud « Tables » de la base mobile
pour vous assurer que l’ensemble des articles ont bel et bien été répliqués :
Effectuez quelques requêtes SELECT sur les tables pour visualiser les données répliquées.
Remarquez que le système de filtres est bien entré en action et que les données répliquées ne
concernent que le technicien Jean Dupont (JDU).
Seule la ligne correspondant à l’agent Jean Dupont a été récupérée pour la table TECHNICIEN. En ce
qui concerne la table DEMANDE_INTERV, elle ne comprend que les demandes affectées à Jean
Dupont. Il en est de même pour les clients, etc.…
www.wygwam.com
www.wygwam.com
IX. Utilisation de la réplication dans le code .NET d’une

application mobile
A. Présentation de la classe SqlCeReplication
Pour rappel, l’initialisation de la synchronisation est à la charge du client, c'est-à-dire le terminal

portable.
Dans le .NET Compact Framework, c’est la classe SqlCeReplication, de l’espace de nom

System.Data.SqlServerCe qui permet de prendre en charge la réplication SQL.
La classe SqlCeReplication possède de nombreuses propriétés qu’il est important de bien définir
selon l’environnement utilisé (web synchro, Publisher, Distributor).
Voici la liste des propriétés importantes de l’objet SqlCeReplication :
Propriétés de la synchronisation web :
• InternetUrl: URL de l’agent de réplication exposé sur IIS.

• InternetLogin: Login du compte utilisateur utilisé pour la connexion au répertoire virtuel IIS.
• InternetPassword: Mot de passe du compte utilisateur utilisé pour la connexion au
répertoire virtuel IIS.
Propriétés du publisher :
• Publisher: Nom de l’instance SQL sur laquelle tourne la base publisher.

• PublisherSecurityMode: Type de sécurité utilisée pour la connexion à la base publisher (NT
ou DB selon si la connexion à la base publisher s’effectue via un compte Windows ou un
compte SQL Server).
• PublisherLogin: Login du compte utilisé pour la connexion au publisher (dans le cas d’un
type de sécurité DB).
• PublisherPassword: Mot de passe du compte utilisé pour la connexion au publisher (dans le
cas d’un type de sécurité DB).
• PublisherDatabase: Base de données publisher à répliquer.
• Publication: Nom de la publication à utiliser.
www.wygwam.com
Propriétés du distributor :
• Distributor: Nom de l’instance SQL sur laquelle tourne la base de distribution (inutile de
préciser dans le cas où le publisher et le distributor sont sur la même machine).
• DistributorLogin: Login du compte utilisé pour la connexion à la base de distribution (inutile
de préciser dans le cas où le publisher et le distributor sont sur la même machine).
• DistributorPassword: Mot de passe du compte utilisé pour la connexion à la base de
distribution (inutile de préciser dans le cas où le publisher et le distributor sont sur la même
machine).
Propriétés du subscriber :
• SubscriberConnectionString: Chaine de connexion à la base de données mobile répliquée.

• Subscriber: Nom de l’abonnement.
• HostName: valeur récupérée pour la fonction de filtrage HOST_NAME().
Propriété de compression :
• CompressionLevel: Cette propriété permet de personnaliser la compression de données. Elle

peut prendre une valeur comprise entre 0 et 6. La valeur 0 désactive toute compression.
En spécifiant une valeur faible pour la propriété CompressionLevel, les données

transmises ne seront pas fortement compressées, ce qui rallonge donc la durée de
transmission. Par contre, plus la valeur est élevée, plus le temps des traitements de compression
sera long sur le serveur exécutant les services IIS, mais la durée de transfert sera d’autant plus
courte. Il est donc question de trouver un juste milieu par rapport aux besoins. Par exemple, si le
coût des données transmises est important pour le projet (forfait opérateur GPRS), il sera
nécessaire d’augmenter la compression de données. Par défaut, la valeur de la propriété est 1.
La définition de l’ensemble de ces propriétés n’est pas obligatoire et dépend entre autre du type de
sécurité utilisé et de la configuration du distributor. Certaines propriétés, quant à elles, doivent
obligatoirement être définies pour pouvoir effectuer une synchronisation, c’est le cas par exemple
des propriétés Subscriber, Publication, InternetUrl, etc.…
En ce qui concerne la chaine de connexion de l’abonnement

(SubscriberConnectionString), il faut savoir qu’il est possible de rajouter la clause « Max
Database Size=X » afin de repousser la limite de taille définie par défaut pour les bases mobiles
répliquées. En effet, par défaut la limite de taille de la base répliquée est fixée à 128Mo. Par
exemple, en précisant « Max Database Size = 1000 » dans la chaine de connexion, la base
répliquée pourra atteindre une taille de 1Go. (La limite maximale réelle étant de 4 Go).
www.wygwam.com
La classe SqlCeReplication présente plusieurs méthodes importantes pour la synchronisation de

données :
• AddSubscription: Cette méthode permet de créer l’abonnement. Cette méthode est

indispensable dans le sens où l’abonnement doit obligatoirement être créé avant de pouvoir
lancer la synchronisation des données. Il est possible de spécifier l’option
« CreateDatabase » pour générer automatiquement la base de données mobile si elle
n’existe pas.
• DropSubscription: Cette méthode supprime l’abonnement lié à la base mobile.
• SaveProperties: Cette méthode permet de stocker l’ensemble des propriétés définies par la
classe SqlCeReplication à l’intérieur d’une table système de la base répliquée.
• LoadProperties: Cette méthode peut être appelée suite à un SaveProperties pour retrouver
l’ensemble des propriétés de la réplication mémorisées sur l’abonné.
• Synchronize: C’est la méthode qui permet de lancer la synchronisation de données en mode
synchrone.
• BeginSynchronize: C’est la méthode qui permet de lancer la synchronisation de données en
mode asynchrone.
La méthode AddSubscription est très importante dans le sens où elle doit

obligatoirement être appelée pour créer l’abonnement avant de pouvoir effectuer une
synchronisation. Si la base de données mobile existe déjà, il est question de préciser l’option
« ExistingDatabase ». Sinon, l’option « CreateDatabase » permettra de générer
automatiquement la base de données par réplication, au chemin spécifié par la chaine de
connexion SubscriberConnectionString.
La méthode LoadProperties est utile par exemple dans le cas où une base mobile serait
générée par réplication en dehors de l’application mobile, et copiée sur l’appareil. Dans ce
cas, il suffit de faire appel à LoadProperties, dans le code de l’application mobile, pour rappeler
facilement l’ensemble des propriétés définies. Suite à un LoadProperties, la méthode
AddSubscription n’a plus besoin d’être appelée. Seules certaines propriétés comme les mots de
passe, ou le HOST_NAME ne sont pas sauvegardées et doivent de nouveau être précisées juste
avant de lancer la synchronisation.
www.wygwam.com
B. Mise en action de la réplication dans le code .NET
Suite à cette présentation théorique de l’utilisation de la réplication SQL dans le code .NET d’une
application mobile, nous allons à présent passer à la pratique.
Dans ce paragraphe, nous allons voir pas à pas comment créer et synchroniser les données d’une
base mobile grâce à la réplication en utilisant la classe SqlCeReplication au sein d’une application
nomade.
Pour cela, nous allons partir d’une application mobile qui ne comporte qu’un unique écran sur lequel
nous avons placé un simple bouton « SYNCHRO » qui va nous permettre de lancer la
synchronisation :
Procédure :
Pour pouvoir utiliser la réplication SQL et plus particulièrement la classe SqlCeReplication, il est
d’abord nécessaire de rajouter une référence à l’assembly System.Data.SqlServerCe en cliquant
droit sur le nœud « References » dans l’explorateur de solutions puis en sélectionnant « Add
Reference » :
www.wygwam.com
Dans la fenêtre suivante, sélectionnez « System.Data.SqlServerCe » puis cliquez sur « OK » :
Dans le code-behind de l’unique « form », nous allons commencer par rajouter un « using » à
l’espace de nom « System.Data.SqlServerCe » :
using System.Data.SqlServerCe;
Ensuite, nous allons définir une constante qui correspond au nom de la base mobile que nous allons
créer par réplication :
private const string _dbName = "technomade_mob.sdf";
Dans le code de l’évènement « Click » associé au bouton synchro, nous allons créer un objet « repl »
de type SqlCeReplication et l’instancier à l’intérieur d’une clause « try-catch-finally » :
private void btnSynchro_Click(object sender, EventArgs e)

{
SqlCeReplication repl = null;
try
{
repl = new SqlCeReplication();
}
catch (SqlCeException ex)
{
MessageBox.Show(ex.Message);
}
finally
{
if (repl != null)
repl.Dispose();
}
}
www.wygwam.com
N’oubliez pas d’attraper les éventuelles SqlCeException dans la clause « catch » et de détruire
l’objet « repl » dans la clause « finally ».
Juste après l’instanciation de l’objet repl, nous allons définir l’ensemble de ses propriétés de telle
manière à pouvoir utiliser correctement les publications PubRef et PubUp que nous avons créées
dans les chapitres précédents de cet article sur la base TECHNOMADE.
Pour rappel, les paramètres corrects correspondants à la configuration précise du publisher et de la

synchro web peuvent être récupérés facilement en créant un abonnement de test via le wizard de
SQL Server (Cf. chapitre VIII.B.).
Dans notre exemple, voici comment doivent être définies l’ensemble des propriétés :
// (...)
repl.InternetUrl = "http://10.10.10.10/webSync/sqlcesa35.dll";
repl.InternetLogin = "pierre.cambier";
repl.InternetPassword = "password";
repl.Publisher = @"DEVNET21-PC\PCAMSQL";
repl.PublisherDatabase = "TECHNOMADE";
repl.PublisherSecurityMode = SecurityType.NTAuthentication;
repl.Publication = "PubRef";
repl.Subscriber = "JDU";
repl.HostName = "JDU";
repl.SubscriberConnectionString = @"Data Source=" + _dbName
+ ";Max Database Size=128;Default Lock Escalation =100;";
// (...)
Remarquez que nous avons remplacé localhost par l’adresse IP du serveur IIS dans l’URL.
A noter également que dans cet exemple nous avons défini la valeur « JDU » pour le HostName,
c'est-à-dire que nous allons ici répliquer une base pour le technicien spécifique Jean Dupont. La
publication sur laquelle la réplication SQL va s’appuyer est la publication PubRef.
Maintenant que nous avons défini l’ensemble des propriétés nécessaires, nous allons rajouter
l’abonnement sur la base en spécifiant que la base mobile doit être générée entièrement par
réplication.
Pour ce faire, nous allons faire appel à la méthode AddSubscription et préciser l’option
CreateDatabase :
// (...)
repl.AddSubscription(AddOption.CreateDatabase);
// (...)
www.wygwam.com
La création de la base mobile et l’ajout de l’abonnement ne sont valables uniquement lors

de la première synchro. En effet, pour les synchronisations suivantes, la base sera déjà
créée et l’abonnement sera déjà présent sur la base. C’est pourquoi, il est intelligent de tester au
préalablement l’existence de la base de données pour effectuer l’ajout de l’abonnement avec
l’option CreateDatabase :
// (...)
if (!System.IO.File.Exists(_dbName))
// (...)
Suite à l’ajout de l’abonnement, nous pouvons enfin appeler la méthode Synchronize qui permet de
lancer la synchronisation. Voici à quoi ressemble à présent le code lié au clic sur le bouton synchro :

{
try
{
repl.Synchronize();
}
{
}
finally
{
if (repl != null)
repl.Dispose();
}
}
www.wygwam.com
Si tout se déroule correctement, lorsque l’utilisateur cliquera une première fois sur le bouton
synchro, cela engendrera la création de l’abonnement et la génération de l’ensemble de la base
mobile. Les données contenues dans la base mobile concerneront uniquement le technicien Jean
Dupont (comme nous avons précisé « JDU » en HostName). Lors des synchronisations suivantes,
l’abonnement ne sera plus de nouveau créé. Seul le différentiel de données modifiées côté serveur
redescendra dans la base mobile.
A ce stade, nous avons donc synchronisé le référentiel de travail du technicien Jean Dupont. Il
dispose à présent d’une base locale sur son terminal qui contient l’ensemble des données qui lui sont
propres (demandes d’interventions, clients, etc…). Nous pouvons d’ailleurs visualiser le fichier
« technomade_mob.sdf » à la racine du terminal sur lequel l’application mobile peut désormais se
connecter et récupérer des données.
Nous allons donc maintenant prendre en charge également la publication qui va permettre au
technicien de remonter ses rapports d’interventions dans la base centrale (PubUp).
Pour prendre en charge plusieurs publications, il suffit par exemple d’effectuer une boucle sur une
liste de publication.
Dans notre exemple, il est préférable de prendre en charge la publication PubUp avant la
publication PubRef. En effet, la mise à jour d’un référentiel de travail est en général
toujours moins importante que la remontée des données saisies sur le terrain. Si la réplication
échoue durant la phase de synchronisation du référentiel, les rapports d’interventions seront tout
de même remontés au central. C’est d’ailleurs pourquoi, dans le cas d’une seule publication dont
les articles sont définis en « Bidirectionnal » (Cf. chapitre VI.C.), c’est toujours la remontée des
données vers le serveur qui a lieu en premier.
www.wygwam.com
Voici le code entier permettant de répliquer les données des techniciens par rapports aux 2
publications qui ont été définies sur TECHNOMADE :

{
try
{
List<string> listPublications = new List<string>();
listPublications.Add("PubUp");
listPublications.Add("PubRef");
foreach (string publicationName in listPublications)

{
repl.Publication = publicationName;
repl.Synchronize();
}
}
{
}
finally
{
if (repl != null)
repl.Dispose();
}
}
Evidemment, il s’agit d’un exemple. Le code de la réplication doit être modulé selon les besoins et
selon les projets.
Dans notre exemple, nous spécifions « en dur » l’identifiant du technicien (HostName de la

réplication). Nous aurions très bien pu créer une nouvelle table nommée TERMINAL dans la base
www.wygwam.com
TECHNOMADE qui aurait permis d’attribuer un terminal spécifique à un technicien selon le numéro
de série de l’appareil.
Les SDK et frameworks utilisés lors du développement d’une application mobile

permettent en général de récupérer très facilement le numéro de série de l’appareil. Nous
aurions donc pu nous baser sur le numéro de série du PDA, au lieu de l’identifiant du technicien,
pour construire le système de filtres et de récupérer les données du technicien rattaché à ce
terminal spécifique (numéro de série unique) :
// (...)
repl.Subscriber = GetSerialNumber();
repl.HostName = GetSerialNumber();
// (...)
C. Exemple d’exécution de la réplication en mode asynchrone
Dans le paragraphe précédent, nous avons écrit un code .NET qui permet de prendre en charge la
génération automatique de la base locale d’un terminal, et de gérer les synchronisations
différentielles de données. Pour exécuter la réplication, nous avons fait appel à la méthode
Synchronize qui réplique les données en mode synchrone (c'est-à-dire que l’exécution de la
méthode Synchronize est bloquante pour l’utilisateur).
Il est tout à fait possible d’exécuter la réplication SQL d’une manière asynchrone (interface graphique
de l’utilisateur non bloqué durant l’exécution de la réplication).
Certes, le code .NET associé à la réplication en asynchrone est plus lourd et plus complexe à écrire,
mais le développeur peut en tirer des avantages précieux surtout en terme de reporting. En effet,
l’exécution de la réplication en asynchrone permet de récupérer des informations utiles comme le
nom des tables en cours de synchronisation, ou encore de connaitre le pourcentage d’avancement
de la réplication.
Pour répliquer de manière asynchrone, il est nécessaire de faire appel à la méthode

BeginSynchronize au lieu de la méthode Synchronize.
La méthode BeginSynchronize peut prendre en argument plusieurs « delegate » qui vont permettre
au développeur de récupérer différents évènements liés à la phase de réplication :
// (...)
repl.BeginSynchronize(new AsyncCallback(SyncCompletedCallback),
new OnStartTableUpload(TableUploadCallback),
new OnStartTableDownload(TableDownloadCallback),
new OnSynchronization(SynchronizingCallback), repl);
// (...)
www.wygwam.com
• La première delegate de type AsyncCallback notifie que la phase de réplication est achevée.
C’est d’ailleurs dans la méthode associée à cette delegate (ici : SyncCompletedCallback)
qu’il faudra nécessairement faire appel à la méthode EndSynchronize de l’objet
SqlCeReplication.
• La seconde, de type OnStartTableUpload, est levée à chaque fois qu’une table est en cours
d’upload. Elle doit absolument recevoir une chaine de caractère en argument qui est
destinée à contenir le nom de la table répliquée.
• La troisième quant à elle, est levée quand une table est en cours de download. Elle doit
absolument recevoir une chaine de caractère en argument qui est destinée à contenir le nom
de la table répliquée.
• Enfin, la dernière permet de notifier régulièrement le pourcentage d’avancement de la
réplication.
Il est donc nécessaire d’écrire convenablement les 4 méthodes delegates associées, en respectant la
bonne signature et les bons arguments :
private void SyncCompletedCallback(IAsyncResult ar)

{
}
private void TableUploadCallback(IAsyncResult ar, string tableName)

{
}
private void TableDownloadCallback(IAsyncResult ar, string tableName)

{
}
private void SynchronizingCallback(IAsyncResult ar, int percent)

{
}
Désormais nous pouvons connaitre le pourcentage d’avancement ainsi que les tables en cours de
réplication, durant le processus de synchronisation.
Nous pouvons ainsi rajouter un label sur la « form » Windows Mobile destiné à afficher ces
différentes informations à l’utilisateur :
www.wygwam.com
Comme dans tous les traitements asynchrones, la réplication SQL lancée via l’instruction
BeginSynchronize se déroulera dans un thread détaché de l’interface graphique (= processus en
arrière-plan). Aussi, il faudra obligatoirement faire appel aux méthodes Invoke pour que le thread de
la réplication puisse accéder et mettre à jour les informations du label créé.
Dans un premier temps, nous créons donc un EventHandler updateStatusHandler que nous
instancions dans le constructeur de la « form » en précisant la méthode qui va permettre de mettre à
jour le statut à l’écran. La variable globale _currentStatus contiendra simplement le statut courant
de la réplication, c'est-à-dire le texte à afficher dans le label :
private EventHandler updateStatusHandler;

private string _currentStatus = String.Empty;
public Form1()
{
InitializeComponent();
this.updateStatusHandler = new EventHandler(UpdateStatus);
}
private void UpdateStatus(object sender, System.EventArgs e)

{
this.lblStatus.Text = _currentStatus;
}
Ensuite, il ne reste plus qu’à compléter les différentes delegates présentées précédemment, c’est à
dire de mettre à jour le contenu de la variable _currentStatus et de faire un « Invoke » de la
delegate updateStatusHandler pour rafraichir les informations :
www.wygwam.com

{
try
{
SqlCeReplication repl = (SqlCeReplication)ar.AsyncState;
repl.EndSynchronize(ar);
_currentStatus = "Synchro OK !";
this.Invoke(updateStatusHandler);
}
{
}
}

{
_currentStatus = "Upload table : " + tableName;
}

{
_currentStatus = "Download table : " + tableName;
}

{
_currentStatus = "Synchro : " + percent.ToString() + "%";
}
Au final, le code complet de la réplication est le suivant :
public partial class Form1 : Form

{
private EventHandler updateStatusHandler;
private string _currentStatus = String.Empty;
public Form1()
{
InitializeComponent();
this.updateStatusHandler = new EventHandler(UpdateStatus);
}
private void UpdateStatus(object sender, System.EventArgs e)

{
this.lblStatus.Text = _currentStatus;
}
www.wygwam.com

{
try
{
repl.BeginSynchronize(new AsyncCallback(SyncCompletedCallback),
new OnStartTableUpload(TableUploadCallback),
new OnStartTableDownload(TableDownloadCallback),
new OnSynchronization(SynchronizingCallback), repl);
}
{
// Catch !
}
finally
{
if (repl != null)
repl.Dispose();
}
}

{
try
{
SqlCeReplication repl = (SqlCeReplication)ar.AsyncState;
repl.EndSynchronize(ar);
_currentStatus = "Synchro OK !";
}
{
}
}

{
_currentStatus = "Upload table : " + tableName;
www.wygwam.com

{
_currentStatus = "Download table : " + tableName;
}

{
_currentStatus = "Synchro : " + percent.ToString() + "%";
}
}
A noter qu’il aurait également été plus astucieux de créer une enumeration des différents statuts de
la phase de réplication, au lieu d’utiliser une variable globale de type string.
D. Réinitialisation d’un abonnement
Pour rappel, un abonnement a besoin de subir une réinitialisation dans les cas ci-dessous :
• Lorsque le schéma de la publication (articles, filtres) a été modifié et que la publication a été
notée « à réinitialiser ».
• Lorsqu’un abonnement expire, suite au dépassement du délai de rétention (Cf. paragraphe
VII.B.)
La réinitialisation d’un abonnement sur le terminal est assurée grâce à la méthode

ReinitializeSubscription de la classe SqlCeReplication.
La nécessité de réinitialiser un abonnement est détectée en attrapant une erreur particulière

(exception) dans la clause « Catch » lors du processus de réplication.
Le code de l’erreur native de l’exception est alors le code 28587.
Si cette erreur particulière est attrapée, cela signifie que l’abonnement a expiré, et la méthode
ReinitializeSubscription doit immédiatement être appelée.
www.wygwam.com

{
switch (ex.NativeError)
{
case 28587:
repl.ReinitializeSubscription(true);
repl.Synchronize();
break;
default:
throw ex;
}
}
Lors de la phase de réinitialisation, l’abonné redescend systématiquement l’ensemble des

données pour reconstruire entièrement sa base mobile. Il s’agit d’une opération très
couteuse en terme de volumétrie, d’où l’importance d’éviter les modifications de schéma sur la
base serveur et de définir une période de rétention correcte.
www.wygwam.com
X. Monitoring des synchronisations
Il est possible de consulter un historique regroupant les différentes synchronisations qui ont eu lieu
sur le serveur.
Pour accéder au monitoring de la réplication SQL, il faut d’abord se connecter à la base publisher.
Ensuite, il faut cliquer-droit sur le nœud « Local Publications » puis sélectionner « Launch
Replication Monitor » :
Une nouvelle fenêtre composée de 3 onglets apparait et permet d’obtenir de nombreuses

informations.
L’onglet « Publications » regroupe les informations générales sur les différentes publications (statut
général, nombre d’abonnements, etc.…) :
www.wygwam.com
Dans la fenêtre ci-dessus, nous pouvons visualiser les 2 publications PubRef et PubUp. La colonne
« Subscriptions » représente le nombre de fois qu’elles ont été chacune synchronisée.
L’onglet « Subscription Watch List », quant à lui, représente réellement l’historique des
synchronisations. Pour chacune des synchronisations, il présente de nombreuses informations
comme :
• Le statut
• Le nom de l’abonnement et l’emplacement de la base mobile répliquée
• Le nom de la publication et du publisher
• Les performances réseau du transfert de données
• La date précise, et la durée de la synchro
Par exemple, la première ligne de la grille ci-dessus correspond à notre premier test de
synchronisation qui a suivi la configuration de la synchro web (Cf. chapitre VIII.B.). Nous avions
synchronisé une base mobile nommée « test.sdf » dans le répertoire « C:\DATA » à partir de la
publication « PubRef » le 21/05/2010 à 15h45. Pour cette synchronisation, le nom de l’abonnement
était « JDU » (= SubscriberName).
Dans notre exemple, si les terminaux mobiles enchainent systématiquement les 2 publications
PubRef et PubUp, il y aura à chaque fois 2 nouvelles entrées dans l’historique.
A noter que la grille de l’historique peut être triée par colonne mais également filtrée grâce au menu
déroulant « Show » :
www.wygwam.com
Il est ainsi possible de ne visualiser que les synchronisations dont le statut est « error » et/ou
« warning ».
En effet, pour chacune des lignes, le statut de la synchronisation est peut-être la colonne la plus
importante puisqu’elle permet de détecter rapidement les erreurs et les problèmes sur les terminaux
mobiles (problèmes de connectivité par exemple).
Nous pouvons dénombrer 4 statuts différents :
• Not synchronizing : lorsque la synchronisation est achevée et qu’elle s’est correctement

déroulée.
• Synchronizing : lorsqu’une synchronisation est en cours.
• Warning : lorsqu’un avertissement a été levé sur une synchronisation particulière.
• Error : lorsque la synchronisation est tombée en erreur.
D’autre part, il est important de signaler que pour une même publication, un même subscriber et un
même statut de réplication, nous avons une seule ligne dans la grille représentant à chaque fois la
dernière synchronisation qui s’est effectuée.
Dans ce cas, pour connaitre l’historique réel des synchronisations pour une publication et un
abonnement spécifique, nous pouvons double-cliquer sur la ligne pour obtenir l’écran suivant :
www.wygwam.com
L’écran ci-dessus représente l’historique des synchronisations qu’a effectué l’abonné « JDU » en
utilisant la publication « PubRef ».
Nous pouvons remarquer 2 lignes :
• La première correspond à la génération de la base mobile et à la descente de toutes données

pour le technicien Jean Dupont.
• La seconde, la plus récente, correspond à la synchronisation normale à partir de
l’abonnement existant.
A noter que cet écran nous présente un niveau de détails assez poussé : il est possible de connaitre
précisément le nombre de lignes répliquées lors d’une synchronisation spécifique (nombre
d’INSERTS, UPDATES, DELETES) :
www.wygwam.com
Enfin, le troisième onglet « Agents » résume la génération des différents snapshots. Il est également
possible de générer un snapshot particulier directement à partir de cet écran. Pour cela, il faut
sélectionner le snapshot dans le tableau puis cliquer-droit et sélectionner « Start Agent » :
www.wygwam.com
Les informations présentées sur ces différents onglets sont entièrement récupérées à
partir de procédures stockées de la base de distribution. Il est tout à fait possible de
récupérer les informations et d’effectuer du reporting sur ces historiques en faisant appel à ces
procédures stockées. Par exemple, l’exécution de la procédure stockée
sp_replmonitorhelpsubscription de la base de distribution permet d’obtenir un reporting complet
équivalent à celui de l’onglet « Subscription Watch List ».
www.wygwam.com
XI. Gestion des conflits
Précédemment, nous avons vu comment nous pouvons éviter les conflits en configurant habilement
les publications et plus particulièrement en séparant en deux publications différentes les tables du
référentiel de celles permettant de stocker les données mises à jour par les terminaux.
Cependant, certaines autres typologies peuvent engendrer l’apparition de conflits.
Dans ce paragraphe, nous allons donc nous attarder un peu sur la cette notion de conflits. Nous
allons voir dans quels cas particuliers ils peuvent apparaitre, comment les détecter et comment ils
peuvent être résolus.
A. Comment naissent les conflits?
L’une des particularités de la réplication de fusion est de disposer de plusieurs bases répliquées sur
les différents terminaux mobiles. Ces différentes bases SQL Server Compact sont toutes des répliquas
d’une seule et même base centrale SQL Server. La réplication permet à toutes ces différentes bases
(base serveur et bases mobiles) de mettre à jour leurs données de manière autonome.
Dans certaines typologies, la réplication peut donc permettre à plusieurs bases d’effectuer des
changements sur la même ligne de données. Lorsque les terminaux concernés synchroniseront avec
la base centrale, il y aura donc un ou plusieurs cas de conflits : quelles mises à jour vont être prises
en compte ? Quelle ligne modifiée sera la « ligne gagnante » d’un conflit particulier ?
Ceci est donc un exemple de cas de conflit très simple à comprendre, mais impossible à reproduire
dans notre exemple TECHNOMADE. En effet, dans le cas de notre solution TECHNOMADE, le
référentiel de l’application est complètement détaché et ne peut pas être mis à jour directement par
les terminaux mobiles. La séparation entre les tables du référentiel et celles des exports terrain est
un très bon moyen de s’assurer que les terminaux mobiles ne modifient pas les mêmes lignes de
données et permet donc d’éviter les conflits.
La plupart des conflits sont liés aux mises à jour de données, cependant il existe d’autres types de
conflits.
Ces conflits peuvent apparaitre aussi bien lors des phases d’upload des données (sens abonné vers
serveur) ou lors des phases de download (sens serveur vers abonné)
www.wygwam.com
Voici quels sont les différents types de conflits que nous pouvons identifier :
• Les conflits de type « update-update » sont causés lorsque la mise à jour d’une ligne sur un
abonné entre en conflit avec une autre mise à jour sur la même ligne sur le serveur. Dans ce
cas, l'outil de résolution par défaut envoie la version gagnante de la ligne vers la base
perdante et journalise la version de ligne perdante dans la table de conflits de l'article.
• Les conflits de type « update-delete » apparaissent lorsqu’une ligne subissant une mise à
jour sur une base a été supprimée sur une autre base. Dans ce cas, c’est le programme de
résolution de conflits qui décidera si la mise à jour sera prise en compte et la suppression
annulée, ou vice-versa.
• Enfin, des conflits de type « failed change » peuvent apparaitre lorsqu’il existe des
différences dans les définitions de contraintes entre la base Publisher et la base répliquée.
Ces différences de contraintes peuvent par exemple générer des conflits de clefs étrangères
ou des violations de clef primaire ou encore de contraintes d’unicité. Pour rappel, c’est lors
de la définition des propriétés des articles qu’il est possible de sélectionner les contraintes et
les objets à prendre en compte dans le processus de réplication.
www.wygwam.com
B. Détection de conflits et niveaux de suivi
Qu'une modification de données provoque ou non un conflit dépend du type de suivi de conflit qui
est défini pour chacun des articles.
Dans le cadre de la réplication de fusion pour SQL Server Compact, il existe deux types de suivis : le
suivi au niveau de la ligne ou le suivi au niveau de la colonne. En fait, ce sont ces deux types de suivis
qui permettent de déterminer comment les conflits sont détectés lors des phases de
synchronisation.
En résumé, voici ce qu’il faut retenir :
• Si le suivi des conflits s’effectue au niveau des colonnes, il y a conflit si des modifications sont
apportées à la même colonne d'une même ligne sur plusieurs nœuds de réplication.
• Si le suivi des conflits s’effectue au niveau des lignes, il y a conflit si des modifications sont
apportées à des colonnes quelconques d'une même ligne sur plusieurs nœuds de réplication
(les colonnes affectées dans les lignes correspondantes ne doivent pas forcément être
identiques).
Le suivi au niveau de la colonne réduit le nombre de conflits quand les applications

mobiles permettent à différents utilisateurs de modifier les mêmes données.
Par exemple, supposons qu'une modification est apportée sur le numéro de téléphone d’un client sur
une ligne de la base de données serveur, et qu'une seconde modification est effectuée sur l’adresse
du client dans la même table de la ligne correspondante de l'abonné. Avec le suivi de niveau ligne, un
conflit est détecté, parce que des modifications ont été faites sur les deux lignes. Avec le suivi de
niveau colonne, aucun conflit n'est détecté, parce que les modifications ont été faites sur des
colonnes différentes dans les lignes.
Peu importe le type de suivi, la résolution du conflit sera identique : toute la ligne de données sera
écrasée par les données du vainqueur du conflit.
Le suivi au niveau de la colonne est un bon moyen de réduire la quantité d'informations

qui doivent être envoyées au serveur de publication au cours de la synchronisation, tandis
que le suivi de niveau ligne nécessite moins de surcharge en matière de suivi, mais a besoin de plus
de stockage pour effectuer le suivi des modifications.
C’est la sémantique des applicatifs qui détermine l’option de suivi à appliquer sur chacun des articles
d’une publication. Dans le cas où la mise à jour de plusieurs champs s’effectue en même temps (ex :
le même écran pour modifier l’ensemble des coordonnées d’un client), il est préférable d’utiliser le
suivi par ligne. Si les mises à jour des champs se font de manière individuelle, le suivi au niveau de la
colonne est le mieux adapté, et permettra d’éviter de provoquer des détections de conflits inutiles.
www.wygwam.com
Une option de suivi est attribuée à un article particulier. Les articles d’une même publication peuvent
avoir des options de suivi différentes selon les besoins.
L’option de suivi, à utiliser pour un article particulier, peut être définie facilement dans les propriétés
des articles. Après avoir sélectionné l’article à éditer, il est question de renseigner le champ
« Tracking level » avec la valeur « Row-level tracking » (suivi de la ligne) ou « Column-level
tracking » (suivi de la colonne) :
Il est également possible de définir l’option de suivi directement dans le script SQL de création d’une
publication, en modifiant le paramètre « @column_tracking » dans la procédure stockée
sp_addmergearticle. La valeur de ce paramètre est « false » pour un suivi de la ligne et « true » pour
un suivi de la colonne.
C. Résolution de conflits et résolveurs
Un programme de résolution de conflits (ou « résolveur ») est associé à chacun des articles de la
publication. Il peut s’agir du même programme, ou d’un programme différent selon les articles et les
besoins.
Lors de la création de la publication et des articles, le résolveur SQL Server par défaut est attribué
automatiquement pour tous les articles. Il est cependant possible de le changer pour en sélectionner
un autre, voire d’utiliser un résolveur personnalisé.
Après la détection d’un conflit, le moteur de réplication lance le programme de résolution de conflits
sélectionné sur l’article (ou celui par défaut) pour déterminer le « vainqueur du conflit ». La ligne
gagnante est appliquée au serveur de publication et à l’abonné tandis que les données de la ligne
perdante sont automatiquement stockées dans des tables systèmes.
www.wygwam.com
Les conflits sont toujours résolus automatiquement par les différents résolveurs et immédiatement
par l'agent de fusion.
Le résolveur par défaut :
Pour utiliser le résolveur de conflits pas défaut, il n’est pas nécessaire d’effectuer des manipulations
particulières de paramétrage. En effet, le résolveur par défaut est automatiquement attribué à
chacun des articles lors de leur création.
Le résolveur par défaut propose plusieurs méthodes de résolution des conflits qui sont généralement
les mieux adaptées aux différentes applications :
• Si un conflit se produit entre la base serveur et un abonné, la modification du serveur est

conservée tandis que celle de l'abonné est annulée.
• Si un conflit se produit entre deux abonnés, la modification provenant du premier abonné
qui se synchronise avec le serveur est conservée tandis que celle provenant du second
abonné est annulée.
Utiliser un autre résolveur :
SQL Server propose toute une liste de résolveurs prédéfinis qui ont chacun des propriétés différentes
en ce qui concerne les résolutions de conflits.
Pour utiliser un autre résolveur sur un article particulier, il est d’abord nécessaire d’entrer dans
l’édition des propriétés de cet article, et de sélectionner l’onglet « Resolver » :
www.wygwam.com
Par défaut, le résolveur par défaut sera sélectionné (« Use the default resolver »). Sélectionnez donc
la seconde option pour choisir un autre modèle de résolveur dans la liste (« Use a custom
resolver ») :
Les méthodes proposées par chacun de ces autres résolveurs sont évidemment différentes et seront
importantes pour déterminer la « ligne gagnante » de chaque conflit. Il est important d’effectuer un
choix judicieux selon les besoins, car il en dépend de la conformité des données de la base.
Par exemple, en sélectionnant le résolveur « DATETIME (Earlier Wins) », le résolveur considèrera

que la ligne modifiée en premier (par rapport à un champ de type DateTime qui doit être précisé)
sera systématiquement la gagnante d’un conflit.
Peu importe le résolveur utilisé, après résolution d’un conflit, l’agent de fusion journalise
systématiquement les données du conflit en fonction du type de conflit dans des tables systèmes, et
par article.
Les données de ces tables de réplication sont purgées au terme de la période de rétention.
Il existe plusieurs procédures stockées qui permettent de visualiser les données de conflits :
sp_helpmergearticleconflicts, sp_helpmergeconflictrows et sp_helpmergedeleteconflictrows.
www.wygwam.com
D. Rédaction d’un résolveur personnalisé
Si vous êtes un peu plus confirmé en matière de réplication SQL, sachez qu’il est tout à fait possible
d’écrire un résolveur de conflits personnalisé en .NET pour répondre à des besoins spécifiques.
La rédaction d’un résolveur en .NET est rendu possible grâce à une API Microsoft qui permet d'écrire
une logique métier personnalisée pour gérer les différents événements qui se produisent au cours du
processus de synchronisation de la réplication de fusion.
Cette API est la DLL « Microsoft.SqlServer.Replication.BusinessLogicSupport » qui se situe par

défaut dans le répertoire « C:\Program Files\Microsoft SQL Server\100\COM ».
D’une manière globale, voici quelles sont les étapes de cette personnalisation :
1. On écrit et on génère une assembly .NET (DLL) qui implémente et « override » les méthodes
nécessaires de la classe « BusinessLogicSupport ».
2. On inscrit la DLL créée sur le serveur de distribution.
3. On déploie la DLL créée sur le serveur où l’agent de fusion s’exécute.
4. On édite les propriétés d’un article pour choisir le résolveur de conflits que l’on vient de
créer.
A titre d’exemple, nous allons imaginer qu’il est possible de modifier l’adresse du client dans notre
application mobile liée au projet TECHNOMADE.
L’article « CLIENT » de notre solution de réplication sera donc soumis à des éventuels conflits lors
d’une synchronisation, si l’adresse d’un client particulier est modifiée à la fois sur le serveur et sur le
terminal mobile synchronisant.
A titre d’exemple, nous allons aussi imaginer une règle simple à mettre en place en cas de conflit
sur l’adresse d’un client :
« Si l’adresse du client modifiée par l'abonné est correctement formatée (numéro + rue + ville), on
doit la garder! Sinon on doit systématiquement conserver celle modifiée par le publisher ».
Nous allons voir maintenant, étape par étape, comment nous devons procéder pour créer un
résolveur de conflits qui applique cette règle !
Création d’une DLL de résolveur :
Pour commencer à écrire notre résolveur, nous allons partir d’un nouveau projet de type « Class
library » dans Visual Studio. De cette manière, nous pourrons facilement compiler une DLL et non un
fichier exécutable.
www.wygwam.com
Pour garder un maximum de similitudes entre cet article et vos éventuelles manipulations, merci de
nommez votre projet « ResolverPerso » et votre classe « ResolverPersoCLIENT » :
Avant toutes choses, il va être également nécessaire d’ajouter une référence à la DLL
«Microsoft.SqlServer.Replication.BusinessLogicSupport ». Pour ce faire, cliquez-droit sur le nœud
«References» dans l’explorateur de solutions puis sélectionnez « Add Références » :
Dans la fenêtre suivante, parcourez le système de fichier pour trouver la DLL

«Microsoft.SqlServer.Replication.BusinessLogicSupport » située par défaut dans le répertoire
« C:\Program Files\Microsoft SQL Server\100\COM ». Cliquez sur « OK » pour rajouter la référence
dans Visual Studio :
www.wygwam.com
Pour commencer, nous allons ajouter les « using » nécessaires :
using System.Data;
using Microsoft.SqlServer.Replication.BusinessLogicSupport;
Puis, dans un second temps, nous allons spécifier que notre classe « ResolverPersoCLIENT » hérite de
la classe « BusinessLogicModule » :
public class ResolverPersoCLIENT : BusinessLogicModule
L’héritage de la classe « BusinessLogicModule » rend obligatoire l’implémentation de la propriété

override « HandledChangeStates » puisque cette dernière est notée « virtuelle » dans la classe mère
« BusinessLogicModule ».
Voici à quoi doit donc ressembler le squelette de départ de notre résolveur :
public class ResolverPersoCLIENT : BusinessLogicModule

{
public ResolverPersoCLIENT()
{
}
public override ChangeStates HandledChangeStates

{
}
}
En héritant de la classe « BusinessLogicModule », il est possible de « overrider » de nombreuses

méthodes afin d’implémenter une logique métier personnalisée sur les différents événements qui se
produisent au cours du processus de synchronisation de la réplication de fusion.
L’ensemble des méthodes qu’il est possible de définir et de personnaliser sont les suivantes :
• CommitHandler : Pour définir des traitements particuliers lors de la validation de données

lors des synchros.
• DeleteErrorHandler : Pour définir des traitements particuliers lorsqu’une erreur se produit
suite à une instruction DELETE.
• DeleteHandler : Pour définir des traitements particuliers lorsque des instructions DELETE
sont exécutées par le processus de réplication.
• InsertErrorHandler : Pour définir des traitements particuliers lorsqu’une erreur se produit
suite à une instruction INSERT.
• InsertHandler : Pour définir des traitements particuliers lorsque des instructions INSERT sont
exécutées par le processus de réplication.
• UpdateConflictsHandler : Pour définir des traitements particuliers lorsque des instructions
UPDATE génèrent des conflits.
• UpdateDeleteConflictHandler : Pour définir des traitements particuliers lorsque des
instructions UPDATE entrent en conflit avec des instructions DELETE.
www.wygwam.com
• UpdateErrorHandler : Pour définir des traitements particuliers lorsqu’une erreur se produit

suite à une instruction UPDATE.
• UpdateHandler : Pour définir des traitements particuliers lorsque des instructions UPDATE
sont exécutées par le processus de réplication.
De cette manière, nous sommes capables de réécrire complètement les logiques de

traitements sur chacun des évènements qui apparaissent lors des phases de
synchronisations ! Pour définir un traitement particulier, il suffit « d’overrider » la méthode liée à
l’évènement concerné et de personnaliser le traitement en y implémentant son propre code.
Evidemment, nous ne sommes pas obligés de réécrire et de personnaliser l’entièreté de ces

méthodes.
Dans notre exemple, ce qui nous intéresse est de proposer une règle particulière de résolution de
conflits pour les conflits de type « update ».
C’est pourquoi, nous allons commencer par déclarer quels sont les types de modifications que nous
allons gérer dans la propriété override « HandledChangeStates ». Il est obligatoire de spécifier ce
que nous allons personnaliser et traiter pour pouvoir capturer correctement les évènements choisis
lors des phases de synchronisations.
Nous allons donc spécifier que nous nous intéressons spécifiquement aux évènements de conflits de
mises à jour à l’aide de l’énumération « ChangeStates » qui contient l’ensemble des types
d’évènements :
public override ChangeStates HandledChangeStates

{
get
{
// On déclare ici quels sont les types de modifications que l'on va gérer
// (dans notre cas, il s'agit des conflits de mises à jour)
return ChangeStates.UpdateConflicts;
}
}
Comme nous avons choisi d’intercepter et de personnaliser les modifications de type « conflits de
mises à jour », nous devons à présent « overrider » la méthode «UpdateConflictsHandler » qui va
nous permettre de spécifier les règles particulières à appliquer lorsque ce type de conflit est levé.
La méthode override «UpdateConflictsHandler » doit respecter une signature particulière. Les

arguments de la méthode correspondent, entre autres, aux éléments importants ci-dessous :
• Un « dataset » qui correspond aux données modifiées par le publisher

• Un « dataset » qui correspond aux données modifiées par le subscriber (abonné)
www.wygwam.com
• Une référence sur un « dataset » personnalisé qui va permettre de personnaliser l’ensemble

des données, suite à un conflit particulier, avant de les renvoyer.
// On personnalise le traitement en cas de conflit de mises à jour:

public override ActionOnUpdateConflict UpdateConflictsHandler(DataSet
publisherDataSet, DataSet subscriberDataSet,
ref DataSet customDataSet, ref ConflictLogType conflictLogType, ref string
customConflictMessage, ref int historyLogLevel, ref string historyLogMessage)
{
// ON DEFINIT ICI LES TRAITEMENTS PERSONNALISES !
}
A présent, à l’intérieur de cette méthode, nous devons écrire la logique de traitement associée. Pour
rappel, nous devons appliquer la règle suivante :
« Si l’adresse du client modifiée par l'abonné est correctement formatée (numéro + rue + ville), on
doit la garder! Sinon on doit systématiquement conserver celle modifiée par le publisher ».
Le code ressemblera donc à ceci :
// On personnalise le traitement en cas de conflit de mises à jour:

public override ActionOnUpdateConflict UpdateConflictsHandler(DataSet
publisherDataSet, DataSet subscriberDataSet,
ref DataSet customDataSet, ref ConflictLogType conflictLogType, ref string
customConflictMessage,
ref int historyLogLevel, ref string historyLogMessage)
{
// On récupère l’adresse du client modifiée par l'abonné:
string adresseAbo = subscriberDataSet.Tables[0].Rows[0]["Adresse"].ToString();
// Si le format de l'adresse, modifié par l'abonné est correct, on la garde,

// sinon, on prend systématiquement celle modifiée par le publisher !
if (FormatCorrect(adresseAbo) == true)
{
// On copie les valeurs du dataset publisher dans un dataset personnalisable:
customDataSet = publisherDataSet.Copy();
// On prend en compte l’adresse modifiée par l'abonné:
customDataSet.Tables[0].Rows[0]["Adresse"] = adresseAbo;
// Renvoi d'un message personnalisé:
customConflictMessage = "Conflit résolu et traité comme il se doit !";
// On valide les modifications effectuées:
return ActionOnUpdateConflict.AcceptCustomConflictData;
}
else
{
// On valide toutes les modifications du publisher:
return ActionOnUpdateConflict.AcceptPublisherData;
}}
Explications :
• Dans un premier temps, nous récupérons l’adresse du client conflictuelle à partir du dataset
de l’abonné.
www.wygwam.com
• Ensuite, nous vérifions le format de l’adresse.

• Si le format de l’adresse est correct, on spécifie explicitement que l’on garde les
modifications effectuées par le publisher.
• Sinon, on copie les données modifiées du publisher dans le dataset personnalisé et on
modifie juste la valeur du champ correspondant à l’adresse par la valeur récupérée de
l’abonné. Enfin, on précise explicitement que l’on valide les données contenues dans le
dataset personnalisé.
A noter que tous les conflits d'un article qui ne sont pas gérés explicitement par la nouvelle logique
métier personnalisée seront gérés par le programme de résolution par défaut pour l'article.
Nous pouvons à présent compiler notre DLL et l’inscrire au niveau du serveur de distribution.
Inscription de la DLL créée sur le serveur de distribution :
La DLL correspondante au résolveur .NET personnalisé étant écrite et générée, nous pouvons à
présent la référencier sur le serveur de distribution.
Cette opération peut être également effectuée en C# grâce à l’API

« Microsoft.SqlServer.Replication.BusinessLogicSupport », cependant il est plus facile d’exécuter
une procédure stockée prévue à cet effet, directement sur la base de distribution.
L’exécution de la procédure ci-dessous, avec les bons paramètres, permet d’inscrire la DLL sur le
serveur de distribution :
USE distribution
GO
EXEC sp_registercustomresolver
@article_resolver = 'Resolveur Perso pour larticle CLIENT',
@is_dotnet_assembly = 'true',
@dotnet_assembly_name =
'C:\DATA\Temp\ResolverPerso\ResolverPerso\bin\Debug\ResolverPerso.dll',
@dotnet_class_name = 'ResolverPerso.ResolverPersoCLIENT'
GO
Il est important de spécifier les bons paramètres :
• @article_resolver : correspond à la description du résolveur.

• @is_dotnet_assembly : doit être à « true » si la DLL a été écrite en .NET.
• @dotnet_assembly_name : correspond au chemin exact de la DLL résolveur à inscrire.
• @dotnet_class_name : correspond au nom de la classe qui comporte le code personnalisé
du résolveur.
L’exécution de cette procédure stockée avec les bons paramètres permet donc d’inscrire
convenablement le résolveur personnalisé sur le serveur de distribution. Il est également important
www.wygwam.com
de déployer le résolveur personnalisé sur le serveur ou l’agent de fusion s’exécute, c'est-à-dire le

serveur web dans notre cas.
Affectation du nouveau résolveur sur un article particulier :
La dernière étape consiste donc à affecter ce nouveau résolveur à un ou plusieurs articles de la

publication.
Pour cela, il suffit de retourner une nouvelle fois sur les propriétés d’un article et de se positionner
sur l’onglet « Resolver ».
Le nouveau résolveur personnalisé qui vient d’être créé doit normalement apparaitre dans la liste
« custom resolver » :
Il suffit de le sélectionner puis de cliquer sur « OK » pour le prendre en compte.
www.wygwam.com
XII. Scripts SQL et procédures stockées pour la replication
Jusqu’à présent dans cet article, nous avons toujours utilisé l’interface graphique de SQL Server
Management Studio, et plus particulièrement les différents wizards, pour créer un système de
réplication de A à Z. Nous avons également vu comment effectuer différentes actions (suppression
d’une publication, monitoring, génération de snapshots, etc…) par le biais de différents menus et
écrans de l’interface SQL Server Management Studio.
Sachez qu’il existe de nombreuses procédures stockées qui permettent d’effectuer toutes ces
actions.
Un administrateur peut tirer profit de ces procédures stockées pour créer facilement des jobs de
maintenance dans SQL Server. Des scripts SQL complets, basés sur les appels à ces procédures
stockées, peuvent être créés et peuvent permettre de planifier des actions intéressantes en termes
de maintenance sur le système de réplication.
Dans ce paragraphe, nous allons donc nous concentrer sur la description de quelques procédures
stockées ayant un rôle précis dans la création ou dans la maintenance d’un système de réplication.
A. Génération d’un script de création de publication
Il est très intéressant de construire une publication en utilisant le wizard de création proposé dans
SQL Server Management Studio (tel que nous l’avons fait précédemment dans cet article).
Le wizard de création a l’avantage d’être « wysiwyg », c'est-à-dire qu’il permet à l’administrateur de

visualiser facilement l’ensemble des actions qu’il entreprend et l’ensemble des propriétés qu’il
attribue à la publication. Il s’agit sans aucun doute de la manière la plus pratique et efficace pour
créer initialement une publication sur une base de données.
Suite à la création et au paramétrage d’une publication par le wizard, il est possible de générer un
script SQL.
La génération d’un script SQL, suite au paramétrage d’une publication, présente également de
nombreux avantages :
• Le script SQL rassemble l’ensemble de la configuration et des paramètres définis pour une
publication particulière (articles, filtres, options, etc…)
• Il est très facile d’enregistrer et d’archiver le script de création
• L’exécution de ce script permet en quelques secondes de régénérer une publication entière
(lors d’un crash par exemple)
www.wygwam.com
Procédure :
Pour générer un script de création d’une publication entière, qui contient l’ensemble du
paramétrage, il suffit de cliquer-droit sur la publication et de sélectionner l’option « Generate
Scripts… » :
La fenêtre qui apparait ensuite permet de sélectionner le type de scripts à générer. Les boutons
radios permettent de spécifier si le script sera destiné à créer ou à supprimer la publication en
question. Nous allons laisser cocher la première option afin de générer un script de création, et non
de destruction :
Le clic sur le bouton « Generate Script » entraine l’apparition d’un menu déroulant.
Sélectionnez « Save to File » pour spécifier que vous souhaitez créer un fichier « .sql » qui va contenir
l’ensemble des instructions SQL de création de la publication entière :
www.wygwam.com
Précisez ensuite le nom et l’emplacement du fichier « .sql » et cliquez sur OK pour lancer la
génération du fichier.
Pour rappel, il est également possible de générer le script à la fin du wizard de création de la
publication :
B. Publications et procédures stockées
Activation de la réplication sur la base Publisher :
La première instruction figurant dans le script de création d’une publication qui a été générée
précédemment est celle qui permet d’activer la réplication de fusion et de définir la base en tant que
« Publisher » :
use master
exec sp_replicationdboption @dbname = N'TECHNOMADE', @optname = N'merge publish',
@value = N'true'
GO
C’est la procédure stockée sp_replicationdboption qui permet cette action.
www.wygwam.com
En passant par l’interface graphique de SQL Server Management Studio, il est possible d’activer ou
de désactiver la réplication de fusion sur une base de données en allant dans les propriétés des
Publishers (clic-droit sur le nœud « Local Publications », « Publisher Properties » puis onglet
« Publication Databases ») :
Ajout de la publication et des comptes utilisateurs :
C’est la procédure stockée sp_addmergepublication qui permet l’ajout d’une nouvelle publication
sur une base de données particulière !
use [TECHNOMADE]
exec sp_addmergepublication @publication = N'PubRef', @description = N'Merge
publication of database ''TECHNOMADE'' from Publisher ''DEVNET21-PC\PCAMSQL''.',
@sync_mode = N'character', @retention = 14, @allow_push = N'true', @allow_pull =
N'true', @allow_anonymous = N'true', @enabled_for_internet = N'false',
@snapshot_in_defaultfolder = N'true', @compress_snapshot = N'false', @ftp_port =
21, @ftp_subdirectory = N'ftp', @ftp_login = N'anonymous', @allow_subscription_copy
= N'false', @add_to_active_directory = N'false', @dynamic_filters = N'true',
@conflict_retention = 14, @keep_partition_changes = N'false',
@allow_synctoalternate = N'false', @validate_subscriber_info = N'HOST_NAME()',
@max_concurrent_merge = 0, @max_concurrent_dynamic_snapshots = 0,
@use_partition_groups = N'true', @publication_compatibility_level = N'90RTM',
@replicate_ddl = 1, @allow_subscriber_initiated_snapshot = N'false',
@allow_web_synchronization = N'true', @allow_partition_realignment = N'true',
@retention_period_unit = N'days', @conflict_logging = N'both',
@automatic_reinitialization_policy = 0
GO
www.wygwam.com
La procédure stockée addmergepublication prend en charge un grand nombre d’arguments qui

correspondent aux propriétés générales de la publication (on y retrouve par exemple la période de
rétention, le choix du répertoire de snapshots ou encore des options sur la gestion des conflits).
Pour plus d’informations sur ces différents paramètres, merci de consulter la documentation
Microsoft : http://msdn.microsoft.com/fr-fr/library/ms176103.aspx.
Juste en dessous de l’ajout de la publication, on retrouve des instructions

sp_grant_publication_access qui permettent d’autoriser l’accès à différents comptes utilisateurs
définis dans SQL Server :
exec sp_grant_publication_access @publication = N'PubRef', @login = ****'

GO
Ajout des différents articles :
L’ajout des articles d’une publication est rendu possible grâce à la procédure stockée
sp_addmergearticle.
Les nombreux arguments liés à cette procédure permettent de définir l’ensemble des propriétés
attachées aux articles. Pour plus d’infos : http://msdn.microsoft.com/fr-fr/library/ms174329.aspx
use [TECHNOMADE]
exec sp_addmergearticle @publication = N'PubRef', @article = N'DEMANDE_INTERV',
@source_owner = N'dbo', @source_object = N'DEMANDE_INTERV', @type = N'table',
@description = N'', @creation_script = N'', @pre_creation_cmd = N'drop',
@schema_option = 0x000000B208034FF1, @identityrangemanagementoption = N'none',
@destination_owner = N'dbo', @force_reinit_subscription = 1, @column_tracking =
N'false', @subset_filterclause = N'', @vertical_partition = N'false',
@verify_resolver_signature = 1, @allow_interactive_resolver = N'false',
@fast_multicol_updateproc = N'true', @check_permissions = 0,
@subscriber_upload_options = 2, @delete_tracking = N'true', @compensate_for_errors
= N'false', @stream_blob_columns = N'false', @partition_options = 0
GO
Ajout des filtres :
Un filtre de réplication peut être construit grâce à la procédure stockée sp_addmergefilter.
use [TECHNOMADE]
exec sp_addmergefilter @publication = N'PubRef', @article = N'DEMANDE_INTERV',
@filtername = N'DEMANDE_INTERV_TECHNICIEN', @join_articlename = N'TECHNICIEN',
@join_filterclause = N'[TECHNICIEN].[IdTec] = [DEMANDE_INTERV].[IdTec]',
@join_unique_key = 0, @filter_type = 1, @force_invalidate_snapshot = 1,
@force_reinit_subscription = 1
GO
www.wygwam.com
Ajout des partitions :
Une partition particulière peut être ajoutée en appelant la procédure stockée

sp_addmergepartition.
use [TECHNOMADE]
exec sp_addmergepartition @publication = N'PubRef', @suser_sname = N'', @host_name
= N'JDU'
GO
Génération du snapshot principal :
La génération du snapshot principal peut s’effectuer en exécutant la procédure

sp_startpublication_snapshot avec les arguments adéquats.
exec sp_startpublication_snapshot @publication = ‘PubRef’
Cette fonction prend en argument le nom de la publication pour laquelle il faut lancer la génération
du snapshot.
Modification des éléments d’une publication :
Plusieurs procédures stockées (préfixées par « sp_change ») permettent de modifier les éléments
des publications ainsi que leurs propriétés (articles, filtres, etc…)
• sp_changemergearticle : est utilisé pour modifier un article de la publication

• sp_changemergefilter : est utilisé pour modifier un filtre particulier de la publication
• sp_changemergepublication : est utilisé pour modifier les propriétés générales d’une
publication
Chacune de ces procédures doit obligatoirement prendre en compte les arguments suivants :
• @publication : le nom de la publication concernée par la modification

• @property : le nom de la propriété à modifier
• @value : la valeur de modification
Exemple :
L’instruction ci-dessous permet de modifier le niveau de suivi pour l’article « CLIENT » de la

publication « PubRef » :
exec sp_changemergearticle @publication = ’PubRef’, @article = ’CLIENT’, @property

= ‘column_tracking’, @value = ‘false’
www.wygwam.com
La suivante permet de redéfinir le délai de rétention de la publication « PubRef » :
sp_changemergepublication @publication = ‘PubRef’, @property = ‘retention’, value =

90
Suppression des éléments d’une publication
Comme pour la modification, des procédures stockées (préfixées par « sp_drop ») permettent de
suppression les éléments des publications.
• sp_dropmergearticle : est utilisé pour supprimer un article de la publication

• sp_dropmergefilter : est utilisé pour supprimer un filtre particulier de la publication
• sp_dropmergepartition : est utilisé pour supprimer une partition définie sur la publication
• sp_dropmergepublication : est utilisé pour supprimer entièrement une publication
Exemple :
L’instruction ci-dessous permet de supprimer entièrement l’article « CLIENT » de la publication

« PubRef » :
exec sp_dropmergearticle @publication = ‘PubRef’, @article = ‘CLIENT’
C. Autres procédures stockées utiles
De nombreuses autres procédures stockées peuvent être utilisées dans le contexte de la réplication
SQL.
Quelques exemples :
• sp_removedbreplication (Cf. chapitre VI.I) : Permet de supprimer rapidement tous les objets
de réplication de la base de données sur laquelle elle est exécutée.
• sp_replmonitorhelpsubscription (Cf. chapitre X.) : Permet d’obtenir des informations de
monitoring de réplication.
• sp_ helpmergearticleconflicts, sp_helpmergeconflictrows et
sp_helpmergedeleteconflictrows (Cf. chapitre XI.C.) : Permet d’obtenir des informations sur
les conflits qui ont eu lieu.
• sp_registercustomresolver (Cf. chapitre XI.D.) : Permet d’inscrire un résolveur de conflits
personnalisé au niveau du distributeur
Lien vers la liste complète : http://msdn.microsoft.com/fr-fr/library/ms174364.aspx
www.wygwam.com
XIII. Optimisation des performances, problématique de la

volumétrie
Tout au long de cet article, nous avons exposé de nombreuses préconisations quant à la mise en
place d’un système de réplication avec des terminaux mobiles.
Ce dernier paragraphe va plus loin, et rentre plus en détails sur les autres aspects possibles en
termes d’optimisations.
Aussi, les aspects techniques décrits dans ce paragraphe ne sont utiles que dans le cadre d’un
système de réplication conséquent, mettant en action un nombre important de terminaux portables
et dont la volumétrie de la base publiée est importante.
Les points présentés ci-dessous ne concernent donc pas notre projet TECHNOMADE.
A. Problématique
La problématique abordée ici est celle des gros projets qui mettent en action un grand parc de
terminaux portables. En effet, la configuration d’un système de réplication fiable se complique
lorsque le nombre d’abonnés devient important. Mettre en place un système de réplication
performant devient surtout un casse-tête lorsque la base centrale est volumineuse et lorsque les
mises à jour sont fréquentes sur cette dernière.
En effet, il faut savoir que lorsqu’un terminal se connecte au serveur, une phase de calculs suit
l’initialisation de la synchronisation. Cette phase de calculs, prise en charge par SQL Server et par
l’agent de réplication, est nécessaire pour déterminer précisément quelles sont les données
modifiées à distribuer sur le terminal connecté. Ces calculs sont d’autant plus longs et complexes
quand la volumétrie de la base est importante et quand le nombre de partitions, c'est-à-dire le
nombre de terminaux abonnés, est conséquent.
De la même façon, la volumétrie de données brassée par les mises à jour sur la base publiée peut
également alourdir considérablement cette phase de calculs. Il faut garder dans l’esprit que plus les
données sont modifiées, plus le processus de réplication mettra du temps pour lister l’ensemble des
lignes qui doivent être descendues sur les différents terminaux. Un système de filtres complexe peut
également avoir des effets négatifs lors de la synchronisation d’un terminal.
www.wygwam.com
La complexité de cette phase de calculs est donc relative à plusieurs points :
• La volumétrie de la base publiée

• Le nombre d’abonnements associés à une publication
• Le système de filtres implémenté sur les articles de la réplication
• La fréquence des mises à jour sur la base publiée et la volumétrie de données brassée durant
ces mises à jour
Dans ce genre de configuration, la synchronisation d’un terminal peut rester bloquée durant
plusieurs longues minutes sur cette phase de calculs avant que le transfert des données modifiées
s’effectue. Pire encore, il est même possible que les calculs n’aboutissent pas et que le système de
réplication tombe en « TimeOut ». Si ce cas se produit, il sera alors impossible de continuer à
synchroniser les PDA ! Il faudra alors augmenter le délai du « TimeOut » par défaut ou effectuer des
manipulations risquées dans les tables systèmes pour continuer à utiliser le système sans détruire les
publications (solutions non acceptables).
Ce genre de problème peut être détecté dans le monitoring des synchronisations (Cf. paragraphe X).
Il se matérialise souvent par des messages d’erreur comme « Timeout expired» ou encore « The
merge process failed to enumerate changes in articles with parameterized row filters ».
A noter que cette problématique doit surtout être prise au sérieux lorsque la base de données
centrale subit des mises à jour en masse suite à l’exécution de traitements de nuit.
Néanmoins, il existe des solutions pour que ce genre de problème n’apparaisse pas !
En effet, il sera nécessaire d’attacher plus d’importance à la manière dont nous configurons les
publications et le système de réplication en général. Cette optimisation passe dans un premier temps
par l’activation de l’option « Precompute partitions »…
B. Activation de l’option « Precompute partitions »
Pour activer l’option « Precompute partitions » sur une publication, il est nécessaire de passer la
valeur de l’option à « true » dans les écrans de paramètres de la publication (page « Subscription
Options ») :
www.wygwam.com
L’option « Precompute partitions » permet d’éviter les phases de calculs durant les
processus de synchronisation. En effet, l’activation de cette option permet d’effectuer le
filtrage et l’archivage des lignes directement lors des mises à jour sur les tables articles.
L’activation de cette option permet donc de préparer au mieux les données à télécharger pour
chacune des partitions.
Concrètement, en activant cette option nous supprimons l’ensemble des calculs qui ont lieu lors de
l’initialisation d’une synchronisation, mais nous rajoutons un traitement supplémentaire en amont, à
chaque mise à jour de données.
L’activation de cette option n’est donc pas sans impact. En effet, une fois activée, les
modifications de données sur les articles par des requêtes INSERT, UPDATE ou DELETE
génèrent un calcul de filtres et mettent donc plus de temps à s’effectuer. Les temps d’exécutions
de ces requêtes doivent rester acceptables dans le cadre de mises à jour en masse par des
traitements de nuit.
www.wygwam.com
Process :
• Une requête (INSERT, UPDATE ou DELETE) est jouée sur une table article
• Le système détermine alors quel terminal est affecté par cette modification (parcours du
système de filtre et des différentes partitions)
• Et ainsi de suite pour l’ensemble des requêtes exécutées lorsque l’option « Precompute
partitions » est activée…
Lorsque le terminal se connecte pour effectuer une synchronisation, toutes les données le
concernant sont déjà prêtes à être transmises. Le transfert de données peut donc avoir lieu
immédiatement.
Avec l’option « Precompute partitions », les temps d’exécution des requêtes sont liés au
nombre de partitions déclarées, mais également au système de filtres implémenté. En
effet, ces temps deviennent vite inacceptables si le système de filtres mis en place est trop
complexe…
C. Simplification du système de filtres
L’activation de l’option « Precompute partitions » est très intéressante mais nécessite souvent de
retravailler le système de filtres pour obtenir des temps de réponses convenables lorsque l’on joue
une simple requête SQL sur la base.
Préconisations pour simplifier le système de filtres :
• Limitez le nombre d’articles filtrés. Les tables non-volumineuses peuvent très bien ne pas
être filtrées. En résultera alors une augmentation du volume des bases répliquées mais qui
devrait être toutefois acceptable.
• Limitez le nombre de niveaux de filtres. Plus l’arborescence de filtres est complexe (en
niveaux de profondeurs), plus les calculs seront difficiles lors de l’exécution d’une requête
sur un article.
Implémenter une arborescence de filtres simple, qui comporte un nombre limité d’articles
filtrés et moins de 2 niveaux de profondeurs, est conseillé pour utiliser convenablement
l’option « Precompute partition ».
www.wygwam.com
Exemple :
Le système de filtres exposé ci-dessous est complexe. Il est composé de 17 tables disposées en 7
niveaux de profondeurs dans l’arborescence. Ce système est mal adapté dans le cadre de l’utilisation
de l’option « Precompute partitions » avec une base volumineuse et un grand nombre de partitions :
Ce système de filtres a été retravaillé pour donner l’arborescence ci-dessous :
Il s’agit d’une arborescence simplifiée, composée de 11 tables disposées en 2 niveaux de profondeurs

seulement.
Pour aboutir à ce système simplifié et adéquat pour l’utilisation du « Precompute partitions », nous
avons dans un premier temps supprimé 6 tables non-volumineuses qu’il n’était pas nécessaire de
filtrer. Ensuite, nous avons « aplati » l’arborescence de telle manière à obtenir un arbre composé de
2 niveaux.
www.wygwam.com
Pour simplifier une arborescence de filtres, il est parfois nécessaire de rajouter des
colonnes sur certaines tables pour pouvoir assurer les jointures SQL nécessaires.
Il est important de signaler que c’est sur les tables « nœuds » de l’arbre (La table 3 dans
l’exemple ci-dessus) que les temps d’exécutions des requêtes seront les plus coûteux. Les
exécutions de requêtes SQL sur l’ensemble des autres tables « feuilles » seront moins coûteuses.
D. Optimisations avancées
Dans le paragraphe précédent, nous avons montré comment optimiser les synchronisations des
terminaux et notamment comment améliorer l’utilisation des « Precompute partitions » en
retravaillant le système de filtres.
D’autres actions peuvent également être entreprises si l’on souhaite aller plus loin en matière
d’optimisations.
Certaines des actions présentées dans ce paragraphe permettent d’optimiser encore plus les mises à
jour sur les articles, tandis que d’autres sont plutôt destinées à accélérer les phases de
synchronisations des terminaux.
Nous pouvons donc distinguer 2 types d’actions :
• Celles qui vont permettre d’optimiser les mises à jour volumineuses. Ces instructions devront
être lancées avant les traitements de nuit par exemple.
• Celles qui vont permettre de préparer au mieux le système pour accélérer les phases de
synchronisations des terminaux. Ces traitements devront être exécutés juste après les mises
à jour en masse.
Certaines actions permettent de préparer au mieux les mises à jour en masse sur la base de données
(s’effectuant par exemple lors des traitements de nuits). Les modifications sur la base, effectuées par
ces actions, devront être rétablies pour que le système soit de nouveau prêt à prendre en charge les
synchronisations de terminaux portables.
www.wygwam.com
Les statistiques :
Pour optimiser au mieux le temps d’exécution des requêtes SQL sur la base centrale, il est
possible d’activer la génération automatique de statistiques.
Les statistiques SQL Server permettent au système de connaitre les meilleurs « plans d’exécution »
pour l’exécution d’une requête particulière. Cette option s’active dans les propriétés de la base de
données (page « Options ») :
Cette option n’altère pas les performances des synchronisations.
Les indexes :
Pour optimiser toujours plus le temps d’exécution des requêtes suite à l’activation des
« Precompute partitions », nous pouvons prêter plus attention aux indexes posés sur les
différentes tables articles.
www.wygwam.com
Pour que les performances des requêtes soient optimales lors de mises à jour en masse :
• On peut placer des indexes de type « nonclustered index » sur tous les champs utilisés dans
les jointures SQL du système de filtres.
• On peut désactiver temporairement les indexes fonctionnels (qui servent uniquement pour
l’application mobile) avant d’exécuter des mises à jour en masse sur la base.
Les indexes que nous désactivons doivent évidemment être réactivés juste après les mises à jour.
L’instruction ci-dessous permet de désactiver l’index « Index1 » défini sur la table « Table1 » :
ALTER INDEX Index1 ON Table1 DISABLE
Pour activer de nouveau un index, il suffit de le reconstruire :
ALTER INDEX Index1 ON Table1 REBUILD
Il est également important de reconstruire régulièrement les indexes pour garder des
performances optimales. En effet, il ne faut pas oublier que certaines lourdes modifications
de données sur la base peuvent considérablement fragmenter les indexes. Cette fragmentation
aura des effets négatifs sur la réplication SQL mais également sur l’application mobile (Les
requêtes SELECT jouées sur la base mobile répliquée seront alors plus lentes).
Le mode « single user » :
Le fait de définir une base de données en « single user » signifie qu’un seul utilisateur (= process)
peut être connecté à la base et effectuer un traitement. Quand un utilisateur a la main sur la base,
les autres process se trouveront systématiquement bloqués et ne pourront pas se connecter à la
base.
Dans notre travail d’optimisation, il peut être intéressant de mettre la base publiée en
« single user » avant l’exécution de mises à jour en masse. En effet, lorsqu’une base est
en « single user », les temps d’exécutions des requêtes sont améliorés car certains traitements de
vérifications et de sécurité des données sont désactivés (par rapport au mode « multi user »).
www.wygwam.com
Quand une base est en « single user », une seule connexion peut s’effectuer (dans notre
cas, ce sera le process qui sera chargé de lancer les requêtes SQL). Autrement dit, tant que
la base de données est en « single user », les synchronisations des terminaux mobiles ne pourront
pas avoir lieu. C’est pourquoi, suite aux mises à jour sur la base, le mode « multi user » doit de
nouveau être réactivé pour que les synchronisations des terminaux puissent se dérouler
correctement.
Pour définir la base en « single user », il suffit de lancer la commande :
ALTER DATABASE TECHNOMADE SET SINGLE_USER WITH ROLLBACK IMMEDIATE
L’option ROLLBACK IMMEDIATE permet de forcer la définition du « single user » sur la base. Si
plusieurs processus tournent, ils seront immédiatement arrêtés.
Pour remettre la base en « multi user » suite à l’exécution des mises à jour, l’instruction suivante
doit être exécutée :
ALTER DATABASE TECHNOMADE SET MULTI_USER
Le degré de parallélisme :
SQL Server détecte le degré de parallélisme optimal, qui correspond au nombre de processeurs
employés pour exécuter une seule instruction. Lors de l’exécution de requêtes SQL, le serveur prend
en compte les plans d'exécution parallèle. Ce parallélisme, c'est-à-dire l’utilisation d’un maximum de
processeurs, joue un rôle très important pour les temps de réponses des requêtes SQL. Pour
permettre au serveur de déterminer le degré maximal de parallélisme, il faut définir cette option à 0.
L’option « max degree of parallelism » avec sa valeur 0, permet de maximiser le

parallélisme avant des mises à jour volumineuses.
Cette option doit être modifiée à l’aide de la procédure stockée sp_configure :
exec sp_configure 'show advanced options', 1

reconfigure with override
exec sp_configure 'max degree of parallelism', 0
A noter qu’il est d’abord nécessaire de définir l’option « show advanced options » à 1 avant pour
avoir accès aux propriétés avancées et pour pouvoir modifier l’option « max degree of parallelism ».
Inversement, pour optimiser les synchronisations de données, il est préférable de minimiser le

parallélisme.
www.wygwam.com
Le parallélisme peut avoir cette fois des effets négatifs lors des phases de synchronisations. En effet,
des verrous (locks) peuvent régulièrement être positionnés sur les tables systèmes à cause du multi
threading.
En choisissant d’utiliser un seul processeur pour les phases de synchros, nous limitons ainsi le
nombre de threads et donc le nombre de verrou (locks) qui seront posés sur les tables systèmes.
Pour supprimer la génération de plans parallèles, il est nécessaire d’attribuer la valeur 1 à l'option
« max degree of parallelism ».
Il est donc préférable de minimiser le parallélisme, juste après les traitements de nuit par
exemple, pour optimiser les synchronisations des PDA.

Période de rétention :
Pour rappel, bien définir la période de rétention d’une publication peut avoir des
conséquences en termes de performances (Cf. paragraphe VII.B.). En effet, si la période de
rétention est trop longue, la volumétrie des métadonnées stockées en tables systèmes deviendrait
alors trop importante et risquerait de fortement réduire le temps d’exécution des mises à jour.
Scripts :
Certaines de ces préconisations doivent être définies une fois pour toute sur la base de données et
sur les publications (période de rétention, régénération des statistiques). Ces options peuvent être
définies facilement à l’aide de l’interface de « SQL Management studio ».
D’autres modifications, comme la désactivation de certains indexes, le mode « single user » ou

encore la définition du parallélisme doivent, quant à elles, être définies avant les processus de mises
à jour volumineuses (traitements de nuit) et doivent obligatoirement être rétablies pour que le
système soit de nouveau prêt à prendre en charge les synchronisations de terminaux portables.
www.wygwam.com
Il peut s’avérer astucieux de créer 2 scripts à exécuter avant et après les mises à jour sur la
base de données.
• Le premier script permettra d’exécuter les actions nécessaires pour optimiser l’exécution des
mises à jour. Ce script devra être lancé par exemple avant les traitements de nuit.
• Le second aura pour but de rétablir la base de données en adéquation avec les
synchronisations des terminaux. Ce script devra être lancé juste après les traitements de
nuit.
Voici un exemple de script qui réunit l’ensemble des préconisations à mettre en place pour optimiser
les mises à jour volumineuses sur la base :
USE [TECHNOMADE]
GO
--Maximisation du parallélisme :
--Définition du mode "single user" sur la base :
ALTER DATABASE TECHNOMADE SET SINGLE_USER WITH ROLLBACK IMMEDIATE
--Désactivation des index fonctionnels :
GO
En exécutant ce script, la base de données fonctionnera de manière optimale pour les mises à jour
volumineuses. Suite à ces traitements, le second script doit être exécuté pour pouvoir de nouveau
assurer les synchronisations :
www.wygwam.com
USE [TECHNOMADE]
GO
--Définition du mode "multi user" sur la base :
ALTER DATABASE TECHNOMADE SET MULTI_USER
--Minimisation du parallélisme :
--Réactivation des index fonctionnels :
GO
E. Profil de distribution
La notion de « profil de distribution » représente un ensemble d’options utilisées par le distributor

lors des phases de transferts de données vers les terminaux portables.
Lors de la configuration du distributor (Cf. chapitre V.) un profil par défaut lui est automatiquement
attribué.
Il existe une astuce pour accélérer les phases de transferts dans le cas où de nombreuses
lignes de données doivent fréquemment être distribuées sur les abonnés. En effet, il est
possible de changer la taille des blocs de données lues et distribuées par le distributeur. Le fait
d’augmenter la taille maximale des blocs (batch) peut accélérer les phases de synchronisations
dans le sens où plus de données sont transférées en même temps.
Procédure :
Pour effectuer cette optimisation, il est d’abord nécessaire d’accéder aux propriétés du distributor.
Pour cela, cliquez-droit sur le nœud « Local Publications » puis sélectionnez « Distributor
Properties » :
www.wygwam.com
Ensuite, sur l’écran ci-dessous, cliquez sur « Profile Defaults… » :
Sur l’écran suivant, vous allez sélectionner l’onglet « Merge Agents » puis cliquer sur « New » pour
créer un nouveau profil pour la réplication de fusion (merge) :
www.wygwam.com
Vous devez ensuite choisir à partir de quel profil existant les valeurs du nouveau profil vont être
copiées. Laissez donc « Default agent profile » puis cliquez sur « OK »:
L’écran suivant présente les valeurs du profil par défaut ainsi que les nouvelles valeurs à définir pour
chacune des options.
Nous allons d’abord spécifier un nom pour ce nouveau profil : nous allons l’appeler « Perso ». Puis,
nous allons modifier la valeur des options « DownloadReadChangesPerBatch » et
« DownloadWriteChangesPerBatch » :
www.wygwam.com
Le fait de définir la valeur 1000 au lieu de 100 pour ces 2 options aura un effet positif sur les temps
de transferts lorsque le nombre de données à transférer sur un terminal sera de l’ordre de plusieurs
centaines de lignes.
En effet, en utilisant ce profil, la distribution se basera sur des blocs de 1000 lignes au lieu de 100
pour transférer les données. Les phases de transfert des synchronisations seront alors accélérées
dans le cas d’une grande volumétrie de données à descendre.
A présent, pour utiliser ce nouveau profil au lieu de celui par défaut lors de la réplication des PDA, il
est nécessaire de préciser son nom via la propriété ProfileName de la classe SqlCeReplication dans
le code .NET de l’application mobile.
Exemple :

// Utilisation d'un profil spécifique:
repl.ProfileName = "Perso";
www.wygwam.com
F. Autres préconisations serveur
Enfin, il faut savoir que de nombreuses bonnes pratiques de configuration du serveur peuvent
également être mises en place dans le cadre d’un lourd système de réplication.
En effet, la configuration du serveur de données peut avoir une grande importance dans
l’optimisation des performances.
Evidemment, plus le serveur hébergeant les bases de données est puissant en termes de mémoire et
de vitesse processeur, plus les performances seront grandes. Il existe cependant quelques
préconisations infra supplémentaires qu’il peut être intéressant de connaitre (que nous ne
détaillerons pas dans cet article).
www.wygwam.com
XIV. Conclusion
Cet article vous a présenté les grands concepts de la réplication de fusion. Il a permis d’illustrer
l’ensemble des points importants pour implémenter un système de réplication conforme dans le
cadre des projets mobiles.
J’espère que mon article vous a plu et qu’il vous a été, ou qu’il vous sera, utile pour mettre en place
un système de synchronisation de bases avec des terminaux sous Windows Mobile.
Encore une fois, la réplication est un produit puissant, riche en fonctionnalités mais assez complexe
en termes de configuration. Il est nécessaire de bien penser sa mise en place et d’effectuer un
paramétrage intelligent et adéquat par rapport aux besoins.
C’est par le biais de plusieurs exemples, et surtout d’un exemple de projet mobile concret que j’ai
réussi à mettre l’accent sur de nombreuses préconisations afin de mieux vous guider pour la mise en
place d’un système de synchronisation.
Pour conclure, sachez qu’il existe encore beaucoup de choses à connaitre sur la réplication de fusion,
mais je pense que les points importants sont tous réunis dans cet article. Cela pourrait faire pourquoi
pas l’objet d’un second article, mais pour le moment je vais en rester là…
XV. Remerciements
Je tiens à remercier l’ensemble des personnes qui m’ont soutenu dans mes travaux et qui m’ont
encouragé à publier mon premier livre blanc.
Je tiens à remercier particulièrement les personnes suivantes, avec lesquelles j’ai eu la chance de
travailler, et qui m’ont fortement conseillé sur le fond et la forme de cet article :
• Grégory Renard, alias « Rédo » (Wygwam)

• Aurélien Verla (Wygwam)
• Pascal Belaud (Microsoft)
• Pierre Cauchois (Microsoft)
• Pascal Deliot (Microsoft)
Pierre Cambier.
pierre.cambier@wygwam.com

Replication Fusion SQLServer Compact

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Replication Fusion SQLServer Compact

Transféré par

Droits d'auteur :

Formats disponibles

2010

Par Pierre Cambier

.NET & Windows Mobile Solution Developer

Microsoft Certified Technology Specialist

[LA REPLICATION DE FUSION AVEC SQL

Wygwam – Lille Wygwam – Paris

Wygwam – Belux Wygwam – Suisse

D. Notions de partitions ................................................................................................................. 55

• Notions en développement d’applications .NET avec Visual Studio.

Ceci est un conseil, une astuce, ou un point important.

II. Principes de la réplication de fusion

Publisher Il s’agit de la base publiée, c'est-à-dire celle qui va être répliquée.

C. Publisher, Distributor et Subscriber

Il existe 2 types de snapshots:

E. Déroulement des synchronisations

Voici comment se déroule la première synchronisation :

• Le distributor utilise le répertoire de snapshots pour préparer le schéma de la base

III. Spécificité de la réplication avec SQL Server Compact

A. Réplication entre un serveur et des terminaux mobiles

Ces bases SQL Server Compact peuvent être :

L’utilisation d’un serveur IIS est indispensable pour implémenter un système de

• Supprimer ou renommer une table

Environnement de - .NET Framework 2.0 (ou versions ultérieures)

Téléchargement des « Microsoft SQL Server Compact 3.5 Server Tools » :

D. Installation et déploiement sur un terminal mobile

Ces composants dépendent du type d’appareil, de plateforme et également du processeur de

IV. Cas d’étude - Base TECHNOMADE

Ce projet est un exemple typique de l’utilisation de la réplication de fusion avec des

B. Description de la base TECHNOMADE

La base TECHNOMADE contient au total 9 tables :

Nous pouvons distinguer 2 groupes de tables :

C. Installation de la base TECHNOMADE

Lien de téléchargement du script de création de la base TECHNOMADE :

Cliquez sur « Next » sur le premier écran du wizard :

Créez donc un répertoire nommé « repldata » à la racine de C: par exemple :

Si vous souhaitez maintenant modifier les propriétés de la distribution, vous pouvez

VI. Configuration des publications

Une publication est rattachée à une et une seule base publisher.

La publication permet de définir l’ensemble des éléments suivants :

• Articles : Ce sont les tables et les colonnes répliquées

Plusieurs publications peuvent être rattachées à une même base.

Dans notre exemple, il est astucieux d’implémenter 2 publications différentes. La première

B. Création d’une nouvelle publication via le wizard

Sur le premier écran du wizard, cliquez directement sur « Next ».

C. Définition des articles

L’écran « Articles » représente la liste des articles définis pour la publication.

Le fait de définir l’ensemble des tables du référentiel en « Download only » permet

D. Définition d’un système de filtres

Il existe 2 types de filtres :

Les filtres « join » permettent de former une arborescence d’articles de la publication.

Les tables sont reliées entre elles à l’aide de jointures SQL.

Filtre d’entrée : WHERE [IdTec] = HOST_NAME()

L’association du « hostname » et de l’identifiant du technicien, sera effectuée dans le code de

Au final, l’arborescence des filtres doit être similaire à l’arborescence ci-dessous :

Interprétation des filtres créés et process :

• Un terminal se connecte au serveur et initialise une synchronisation en exposant l’identifiant

Et ainsi de suite pour les villes et les voies…

La complexité de l’arborescence des filtres peut être un inconvénient au niveau des

En ce qui concerne la remontée des rapports d’interventions (2ème publication), nous

E. Propriétés de l’agent de snapshots

Il s’agit de la dernière étape de configuration de la publication. Il est ici question de préciser si la

A noter que le rafraichissement périodique et automatique du snapshot permet au moteur de

Cliquez sur le bouton « Next » pour accéder au prochain écran :