réplication transactionnelle dans les 2 sens

[zalalus]

Bonjour,
J’essaye de réaliser une réplication transactionnelle entre 2 BD(sur 2 serveurs #)
situation actuel
J’ai une BD1 qui contient une table test1 et une BD2 qui contient la table test1.
j'ai arrivé à réaliser une réplication transactionnelle de bd1.test1=>bd2.test
mais lorsque j'essaye de mettre une autre réplication de l'autre sens(bd2.test1=>bd1.test).
Message d'erreur
un message d'erreur est signalé au niveau de l'agent de distribution "Impossible de trouver la procédure stockée 'sp_MSupd_test'."

pourtant j'ai suivi les mêmes étapes que la première

des idées?
merci d'avance

[kagemaru]

normalement, pour créer un répli dans les 2 sens tu as 2 choix : par fusion ou bidirectionnelle (avec abonnements modifiables).
Ce que tu veux faire me semble impossible ...
quelles options as-tu renseigné lors de la création de ta publication sur bd2 ?

[SQLpro]

Il n'est pas possible d'utiliser le mode transactionnel pour une réplication bilatérale sauf si les articles concernés ne se recouvrent pas. Par exemple TableX répliqueée de A vers B et table Y répliquée de B vers A.

Dans le cas d'une réplication bilatérale vous devez utiliser le mode fusion.

A +

[zalalus]

je tiens à vous remercier pour votre réponse

si j'ai bien compris,il est impossible de réaliser deux publication transactionnelle différents(une de a->b et l'autre de b->a).
kagemaru m'a proposé de réaliser cet architecture soit par fusion ou bidirectionnelle (avec abonnements modifiables).
à ma connaissance, il existe trois type de réplication (instantané,transactionnelle,fusion)
vous pouvez m'expliquer(bidirectionnelle (avec abonnements modifiables).)
merci d'avance
sinon si quelqu'un a une autre idée why not

[kagemaru]

la transactionnelle avec abonnements modifiable marche comme une transactionnelle classique mais peut renvoyer des modifs sur la table publié par 2 moyens :

en modif immédiate le MSDTC est utilisé en faisant une transaction en commit à 2 phases (ce mode est un peu risqué car pour valider la modif sur l'abonné il faut d'abord le valider sur l'éditeur : donc en cas de coupure réseau, la table abonnées peut être bloquée en màj)

en modif par file d'attente : à ce moment là un agent, le queue agent, va stocker les mises à jour sur les tables abonnées et les rejoue sur l'éditeur tout de suite ou en différé si besoin (configurable).

L'inconvénient majeur est la gestion des conflits (mise à jour simultanée d'un même enregistrement des 2 côtés) car SQL Server remonte une erreur et il faut choisir la mise à jour qui "a raison".

La réplication type fusion est plus recommandée pour des petits volumes (bien que MS dise le contraire, pourtant c'était bien prévu pour ça lors de l'invention du procédé), typiquement pour des gens mobiles qui se connectent à une base centrale de tps à autre.

Il faudrait décrire un peu plus le fonctionnement de l'application car la mise en place d'une répli est fortement lié au type d'application.

[zalalus]

Rebonjour

voila le fonctionnement de l'application :
j'ai besoin de synchroniser entre 5 BD, La Bd principale se trouve sur un serveur et le reste (4 restants) se trouvent sur un serveur distant.
j'ai réalisé une réplication de fusion entre BD1->Bd2 qui tourne parfaitement(comme test).
Mnt je veux surtout réaliser une réplication de fusion dynamique, c'est pour ça que j'ai utilisé les filtres dynamique,mais lorsque je teste cette requête SELECT <colonnes_publiées> FROM [dbo].[table1] WHERE .[table1].code=CONVERT(int,HOST_NAME()) un message d'erreur est signalé comme quoi il est impossible de réaliser cet conversion
j'ai trouvé cet article http://technet.microsoft.com/fr-fr/library/ms152478.aspx et j'ai respecté les différentes étapes mais c'est tjrs le même message d'erreur
Des idées????
Merci d'avance