2

Version serveur: SQL Server 2008R2 Version client: SQL Server Express 2008R2réplication de fusion - Triggers tir sur deux Editeur et l'Abonné

J'ai rencontrais ce qui semble être les problèmes de verrouillage lorsque je lance mon processus de réplication de fusion. Il semble être quand une modification est faite sur l'abonné et synchronisé avec l'éditeur. Je suis positif vient des déclencheurs parce qu'il semble qu'ils tirent encore sur l'éditeur et essayent probablement d'envoyer des données aux abonnés encore. J'ai ajouté "PAS POUR RÉPLICATION" aux déclencheurs, mais cela ne semble pas aider. J'ai aussi fait des recherches et essayé d'ajouter la clause ci-dessous.

DECLARE @is_mergeagent BIT 

SELECT @is_mergeagent = convert(BIT, sessionproperty('replication_agent')) 

IF @is_mergeagent = 0 --IF NOT FROM REPLICATION 

Cela n'a pas semblé aider non plus. Comment gérez-vous la réplication de fusion avec des déclencheurs d'insertion/mise à jour? Puis-je les empêcher de tirer "Double"?

Toujours apprécier l'info.

-S-

+0

Voulez-vous dire qu'ils sont aussi tirer sur l'abonné? –

+0

Salut Aaron, Il se déclenche sur l'insertion initiale sur l'abonné puis quand il se déclenche sur l'éditeur (Création d'une deuxième entrée quand il ne devrait pas) puis cette deuxième entrée revient à l'abonné dans le même cycle de synchronisation .. ... qui semble causer le verrouillage. – scarpacci

Répondre

2

Je ne suis pas sûr que les triggers se déclenchent mais SESSIONPROPERTY donnera NULL ici. Donc, le test subséquent échoue toujours.

<Any other string> [donne] NULL = L'entrée n'est pas valide.

Vous voulez dire probablement APP_NAME

Cela devrait au moins aider le dépannage ...

1

je voudrais ajouter un champ de bits à la table qui est à l'origine de la question et l'appeler « traité » ou quelque chose comme ça. l'avoir par défaut à false, puis mettre à vrai lorsque le déclencheur met à jour cet enregistrement, et que le déclencheur vérifie une valeur false avant de faire quoi que ce soit, sinon il ne fait rien.