Discussion :

[Romers]

Bjr,
J'ai mis en place une structure de base de données dont certaines tables contiennent des données de référence qui peuvent être mises à jour quotidiennement.

Je dois permettre à nos clients de récupérer ces données dans un moment hors activité (la nuit par ex).

Pour celà, j'ai mis en place (sous forme de proto) la réplication de fusion.
Je crée une publication qui fait une capture instantanée.
Mes abonnés récupère la capture instantané et peuvent ainsi se mettre à jour quand il le souhaite grace à leur abonnement à la réplication.
Les données ne transitent que dans un sens (serveur vers abonnés) mais je n'interdis pas au client d'entrer des données dans sa propre base.

Ceci ne pose pas de problème du moment qu'on ne touche pas grand chose à la structure de la BDD (suppression de colonnes, ajout de colonnes, saisie de données).

Si par exemple pour un besoin d'évolution je dois modifier la structure de ma BDD, une clé primaire d'une table ou ajouter des contraintes ou des filtres, etc. alors le serveur de publication me demande de regénéré la capture instantanée.

Ceci a pour résultat de devoir republier chez mes abonnés cette nouvelle capture et ils perdront toutes leurs données saisies en local (puisque je le rappelle, je n'accepte pas sur le serveur des données de l'abonné).

Quelqu'un peut-il me proposer une solution ou un paramétrage de cette réplication?
J'ai peut être choisi un moyen trop compliqué ou peu adapté.

Merci par avance.

Précision: Je travaille avec SQLServer 2005, Windows 2003 Server

[kagemaru]

bonjour,

est-ce qu'il y a beaucoup de tables modifiées côté utilisateurs abonnés ? Est-ce que les abonnés sont en 2005 également ?

merci

[Romers]

Le principe est d'avoir une BDD maitre qui possède qq tables de référence contenant des données, les autres étant vide. La réplication est effectuée sur cette base.

Lors de l'installation d'un client, je viens l'abonner à la réplication pour que la BDD soit répliquée sur mon client.

Supposons, que ma BDD maître doit être modifiée suite à une évolution de mon logiciel. Je déplace une colonne par exemple. J'ai le message suivant:
table 'CLIENT (dbo)'
- Impossible de modifier la table.
Il n'est pas possible de supprimer la contrainte par défaut portant sur la colonne rowguid ; elle est utilisée par la réplication de fusion.
Échec de l'opération DDL à l'intérieur de la manipulation de réplication DDL.
La transaction s'est terminée dans le déclencheur. Le lot a été abandonné.
Dans ce cas, je ne peux pas valider ma modif. Je suis donc obligé de revenir en arrière. (C'est pas vital de changer l'ordre des colonnes mais c'est pour l'exemple)

J'ai des messages similaires lorsque je change le type d'une colonne que je sais vide. (C'est pas très malin mais c'est pour tester)


Côté client abonné, mon application vient remplir les tables. Mais la réplication ne récupère jamais ces données. Elles sont uniquement pour le client abonné. Certaines tables sont donc en téléchargement seule et d'autre, j'autorise à ajouter des champs.

Le but est de proposer à nos clients une mise à jour de leur BDD (données et structure) à distance. Par contre, les données qu'ils saisissent, on s'en fout. Bien entendu, les modifications de la BDD ne doit pas tout chambouler les données déjà saisies par les clients.
De plus, lors de l'installation d'un nouveau client, on crée l'abonnement et hop, ça lui crée sa BDD suivant le dernier Master. La réplication est configurée pour le Web et ça marche pas trop mal.

Ensuite, j'ai d'autres erreurs. J'ajoute une contrainte sur une colonne d'une table. Je peux sauvegarder cette modif. Ouf! Mais lors de l'éxécution de la mise à jour de mon client abonné, j'ai l'erreur:
Le script de schéma « if object_id(N'[Reference].[PAYS]') is not null exec('ALTER TABLE [Reference].[PAYS] WITH CHECK ADD
CONSTRAINT [CK_PAYS] CHECK
(([dbo].[CheckIdTraduction]([PAYS].[RefIdTraduction])=(1)))') » n'a pu être propagé vers l'abonné.

J'espère que tout ça est compréhensible.
Merci.

[Dustykkv]

Pour ma part, j'aurai opté pour une réplication de fusion sur les tables de référence uniquement. Les autres tables ne devraient pas être répliquées (celles que les clients saisissent sur les abonnés, sans remontée vers le serveur). L'inconvénient est que les mises à jour de structure ne se font pas automatiquement, mais vous gagnerez en souplesse pour modifier la structure, il vous suffira de renvoyer des scripts SQL (CREATE, ALTER...) à passer sur les abonnés. Les données ainsi saisies ne seront pas supprimées.

Plus généralement il me semble que la réplication de fusion est utile pour répliquer les données (et au travers, SQL Server propose des fonctions pour répliquer des éléments de structure). Néanmoins la fonctionnalité est surtout utile pour la réplication des données. Si les données de vos abonnés ne doivent pas remonter sur le serveur, il ne faut pas les inclure dans la publication je pense.

Cdlt,
Kevin