Nous avons cr=E9=E9 une r=E9plication de fusion entre 2 SQL2000
Les processus de r=E9plication se deroulent sans probl=E8me=20
depuis quelques jours.
Recemment nous avons =E9t=E9s contraint de supprimer une=20
publication sur l'=E9diteur pour y faire
des modifications.
Apr=E9s avoir reconfigur=E9 la publication (en lui donnant un=20
autre nom) et les abonn=E9s,
puis appliqu=E9 la capture instantan=E9e : la r=E9plication=20
=E9choue. (aucun transfert de donn=E9es)
la reinitialisation de l'abonnement =E9choue =E9galement.(
Il semble que l'abonn=E9 conserve des traces de l'ancien=20
abonnement =E0 la publication et=20
notamment une table qu'il est impossible de supprimer=20
(message: impossible de supprimer car utilis=E9e pour la=20
r=E9plication)
Nous avons essay=E9 plusieurs proc=E9dures stock=E9es systemes=20
cot=E9 abonn=E9 sans r=E9sultat
(sp_subscription_cleanup,sp_droppullsubscribtion,etc...)
Est que quelqu'un connait la proc=E9dure pour supprimer=20
toutes traces d'abonnement envoy=E9
=E0 une publication du cot=E9 des abonn=E9s?
Nous sommes compl=E8tement bloqu=E9s, la suppression de la=20
table etant impossible.
Nota :
Lors de la suppression d'une publication, il est=20
necessaire de supprimer les abonn=E9s au pr=E9alable
et il semble que cela n'a pas =E9t=E9 fait.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Zip
>Est que quelqu'un connait la procédure pour supprimer toutes traces d'abonnement envoyé à une publication du coté des abonnés?
Peut etre une piste qui ne coute pas grand chose...
Moi j'ai eu des problemes semblables et j'ai fait un backup de la base "principale" puis copie du backup sur le 2eme serveur, puis restauration de la base, puis recreation de la publication, puis reabonnement (en cochant la case qui dit que l'abonné possede déjà le schema pour gagner du temps...).
Tenez nous au courant.
>Est que quelqu'un connait la procédure pour supprimer
toutes traces d'abonnement envoyé
à une publication du coté des abonnés?
Peut etre une piste qui ne coute pas grand chose...
Moi j'ai eu des problemes semblables et j'ai fait un backup de la base
"principale" puis copie du backup sur le 2eme serveur, puis restauration de
la base, puis recreation de la publication, puis reabonnement (en cochant la
case qui dit que l'abonné possede déjà le schema pour gagner du temps...).
>Est que quelqu'un connait la procédure pour supprimer toutes traces d'abonnement envoyé à une publication du coté des abonnés?
Peut etre une piste qui ne coute pas grand chose...
Moi j'ai eu des problemes semblables et j'ai fait un backup de la base "principale" puis copie du backup sur le 2eme serveur, puis restauration de la base, puis recreation de la publication, puis reabonnement (en cochant la case qui dit que l'abonné possede déjà le schema pour gagner du temps...).
Tenez nous au courant.
marc34
Oui mais les 2 postes sont distants de 120 km (la replication s'effectue par ligne RTC), et il faudrait envoyer la sauvegarde par la poste (100mo). De plus le serveur SQL abonné est MSDE donc sans Enterprise Manager donc sans possibilité de recréer la publication, ou alors en administration à distance et je ne suis pas sur que MSDE accepte d'etre editeur de publication.
Nous poursuivons les recherches et espèrons une autre solution à notre problème.
Sinon il faudra se resoudre à appliquer celle que vous proposez.
Merci
Oui mais les 2 postes sont distants de 120 km (la
replication s'effectue par ligne RTC),
et il faudrait envoyer la sauvegarde par la poste (100mo).
De plus le serveur SQL abonné est MSDE donc sans
Enterprise Manager donc sans possibilité de
recréer la publication, ou alors en administration à
distance et je ne suis pas sur que MSDE
accepte d'etre editeur de publication.
Nous poursuivons les recherches et espèrons une autre
solution à notre problème.
Sinon il faudra se resoudre à appliquer celle que vous
proposez.
Oui mais les 2 postes sont distants de 120 km (la replication s'effectue par ligne RTC), et il faudrait envoyer la sauvegarde par la poste (100mo). De plus le serveur SQL abonné est MSDE donc sans Enterprise Manager donc sans possibilité de recréer la publication, ou alors en administration à distance et je ne suis pas sur que MSDE accepte d'etre editeur de publication.
Nous poursuivons les recherches et espèrons une autre solution à notre problème.
Sinon il faudra se resoudre à appliquer celle que vous proposez.
Merci
MARC34
Aprés de longues recherches nous avons trouvé une solution.
C'est la procédure sp_DropMergePullSubscription qu'il faut utiliser sur le serveur abonné, et dans la base abonné.
Cette sp supprime (entre autres) les déclencheurs sur les tables en abonnement de fusion,et les entrées dans les tables SysMergePublications, et sysMergeSubscriptions...
Un test consiste a essayer de renommer une table figurant comme article de la publication (Avant execution de la sp impossible, après possible.)
Reste un flou concernant 'PULL': en effet il s'agit de supprimer un abonnement ENVOYE par l'éditeur donc PUSH. Peut etre que ce genre d'abonnement est considéré comme PULL du coté de l'abonné ??? Enfin ça marche.
Aprés de longues recherches nous avons trouvé une solution.
C'est la procédure sp_DropMergePullSubscription qu'il faut
utiliser sur le serveur abonné,
et dans la base abonné.
Cette sp supprime (entre autres) les déclencheurs sur les
tables en abonnement de fusion,et les entrées dans les
tables SysMergePublications, et sysMergeSubscriptions...
Un test consiste a essayer de renommer une table figurant
comme article de la publication
(Avant execution de la sp impossible, après possible.)
Reste un flou concernant 'PULL': en effet il s'agit de
supprimer un abonnement ENVOYE par l'éditeur donc PUSH.
Peut etre que ce genre d'abonnement est considéré comme
PULL du coté de l'abonné ???
Enfin ça marche.
Cette sp supprime (entre autres) les déclencheurs sur les tables en abonnement de fusion,et les entrées dans les tables SysMergePublications, et sysMergeSubscriptions...
Un test consiste a essayer de renommer une table figurant comme article de la publication (Avant execution de la sp impossible, après possible.)
Reste un flou concernant 'PULL': en effet il s'agit de supprimer un abonnement ENVOYE par l'éditeur donc PUSH. Peut etre que ce genre d'abonnement est considéré comme PULL du coté de l'abonné ??? Enfin ça marche.
