Introduction
Cet article, traitant de la réplication SQL Server 2005 et du contrôle de cette dernière par le code se divise en deux parties. Dans la première, nous reviendrons sur les grands conceptes de base de la réplication de données avec SQL Server 2005. En effet, nous verrons un peu de théorie sur le fonctionnement de cette réplication, mais surtout nous verrons toutes les étapes nécéssaires à la mise en place de cette dernière (de type fusion dans ce cas) afin de pouvoir l'utiliser par la suite.
Dans une seconde partie, nous étudierons les outils mis à disposition par Microsoft pour le contrôle de la réplication SQL Server par le code. Nous nous intéresserons plus particulièrement à RMO (Replication Management Object) et SMO (SqlServer Management Object).
Afin de sortir un peu du domaine théorique, nous construirons une application console basique nous permettant de contrôler le processus de réplication entre deux bases de données que nous aurons mis en place dans la première partie de l'article.
Les prérequis pour la lecture de cet article sont une bonne connaissance du fonctionnement de la réplication SQL Server, ainsi que des notions basiques de développement en langage C#. Tous mes exemples de codes seront rédigés en C# 2.0.
Vous devez disposer d'au moins un serveur hébérgeant SQL Server 2005 (2 préférables pour apporter plus de réalisme) ainsi que d'un IDE de développement .NET (Visual C# Express amplement suffisant).
Mise en place de la réplication de fusion entre deux bases MS SQL Server identiques
Dans cette première partie, je vous expliquerai comment créer une publication de base de données par réplication de fusion et y abonner un serveur, lorsque les bases de données contiennent déjà des données identiques sur chacun des serveurs.
La réplication de base de données SQL Server 2005 repose sur le principe du distributeur/abonné.
En effet, un serveur met à disposition une ou plusieurs publications d’une de ses bases de données ou une partie (c’est le distributeur), un autre vient s’abonner à une de ces publication (c’est donc l’abonné).
Le principe de réplication de fusion repose sur le fait que l’abonné comme le distributeur peut faire part de ses modifications à l’autre et que les données vont êtres fusionnées sur chacune des deux bases. Cependant, le serveur de publication aura toujours l’avantage sur les données en cas de conflit.
Pour faire simple, seules les modifications seront publiées.
Je tiens aussi à préciser que les triggers de base de données sont exécutés lors d’une réplication, à moins que ceux-ci n’aient été crées avec l’attribut NOT FOR REPLICATION. De même, les contraintes de clés étrangères sont conservées pendant la réplication, évitant ainsi tout conflit qui pourrait se révéler dangereux pour l’intégrité des données répliquées.
Ce processus permet donc d’avoir 2 bases IDENTIQUES sur nos serveurs.
Lire la suite