[SQL2005] Réplication avec fusion - comment corriger l'erreur "25001" ?

[emmanuel95]

J'ai une base SQL Server 2005 Standart edition sur notre serveur, et des postes clients en SQL Server Compact edition, et une réplication avec fusion entre le serveur et les postes client : les données concernant les produits sont répliquées sur les postes clients, et les données des ventes sont remontées sur le serveur.
Récemment j'ai mis à jour la table produits sur le serveur : update de lignes existantes et insert de nouvelles lignes (avec le SQL Server Management Studio).
Suite à ces modifications, la replication affichait le message d'erreur :
"Les informations de version du schéma de l'Abonné sont incohérentes par rapport aux informations de version du schéma du serveur de publication. Le serveur de publication a probablement été restauré à partir d'une sauvegarde dont la version des modifications de schéma diffère de celle de l'Abonné. Réexécutez l'agent de capture instantanée et réinitialisez les abonnements."

=> J'ai relancé l'agent de capture, et réinitialisé les abonnements, et maintenant lors de la réplication j'ai ce fameux message d'erreur :
"25001 : Soit le curseur ne se trouve pas sur une ligne, soit il ne reste plus de lignes."

Je n'ai rien trouvé sur cette erreur, et je ne sais pas comment la corriger.

Remarque : Pour tester j'ai réinstallé complètement un poste client, avec suppression de la base locale, et la base se recrée correctement en local lors de la replication. L'erreur 25001 ne se produit que sur des postes qui étaient déjà installés avant mes modifs.

Quelqu'un a t il déjà rencontré cette erreur?
Merci d'avance pour tout indice!

Et Bonne Année à vous!

[kagemaru]

bonjour,

cette erreur ne me dit rien.

Est-il possible de donner des détails sur la table et les commandes lancées ?

Merci

[emmanuel95]

A propos de la table, j'ai ressorti le script de création de la table, avec les contraintes liées à la réplication :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
USE [MA_BASE]
GO
/****** Objet :  Table [dbo].[MDS_PRODUIT]    Date de génération du script : 01/11/2008 17:22:03 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[MDS_PRODUIT](
	[PRO_ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
	...
	[rowguid] [uniqueidentifier] ROWGUIDCOL  NOT NULL CONSTRAINT [MSmerge_df_rowguid_6B4DD734279440D2BB194255D4939A87]  DEFAULT (newsequentialid()),
 CONSTRAINT [PK_MDS_PRODUIT] PRIMARY KEY NONCLUSTERED 
(
	[PRO_ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO
ALTER TABLE [dbo].[MDS_PRODUIT]  WITH CHECK ADD  CONSTRAINT [FK_MDS_PROD_FK_PRODUI_MDS_FORM] FOREIGN KEY([PRO_FOR_ID])
REFERENCES [dbo].[MDS_FORME] ([FOR_ID])
GO
ALTER TABLE [dbo].[MDS_PRODUIT] CHECK CONSTRAINT [FK_MDS_PROD_FK_PRODUI_MDS_FORM]
GO
ALTER TABLE [dbo].[MDS_PRODUIT]  WITH NOCHECK ADD  CONSTRAINT [repl_identity_range_48FE83D1_1ECC_4DB7_8F62_80977C4323DE] CHECK NOT FOR REPLICATION (([PRO_ID]>(45171) AND [PRO_ID]<=(46171) OR [PRO_ID]>(46171) AND [PRO_ID]<=(47171)))
GO
ALTER TABLE [dbo].[MDS_PRODUIT] CHECK CONSTRAINT [repl_identity_range_48FE83D1_1ECC_4DB7_8F62_80977C4323DE]

Voici les requêtes de mise à jour :
- j'ai lancé un premier script composé d'environ 13000 lignes, où chaque ligne était du type:

Code :

UPDATE PRODUIT SET COLONNE1 = 'texte' WHERE PRO_ID = XXX

Suite à cette première modif, la réplication s'est bien déroulée, sans erreur.

- ensuite j'ai lancé un 2ème script du même genre, d'environ 11000 lignes, mais qui mettait à jour une autre colonne :

Code :

UPDATE PRODUIT SET COLONNE2 = 'texte' WHERE PRO_ID = XXX

Ensuite j'ai importé mes nouvelles données dans une table 'tampon' (non répliquée), et j'ai lancé une requete d'insertion à partir de cette table tampon :

Code :

1
2
3
INSERT INTO PRODUIT[liste des champs] SELECT[liste des champs]
FROM table_tampon 
WHERE PRO_ID NOT IN (SELECT DISTINCT PRO_ID FROM PRODUIT)

Résultat : environ 1300 lignes insérées.

Suite à cette deuxième série de modifs, lors de la réplication j'ai rencontré la première erreur "Les informations de version du schéma de l'Abonné sont incohérentes ..." (voir ci dessus).
Donc j'ai suivi les indications du message d'erreur (Agent de capture instantané relancé, et abonnements réinitialisés).

Lors de la réplication suivante, dans le moniteur de réplication, la réplication était en erreur avec le message '25001' (voir image jointe)

Le message d'erreur contient un lien vers une aide Microsoft, mais malheureusement ce lien n'est pas très utile...
http://www.microsoft.com/products/ee...er&EvtID=25001

Voilà... en espérant que cela vous donne plus d'informations!

[SQLpro]

La réplication de fusoin ne peut pas fonctionner si vous faites des fichiers COBOL et non des tables.

je vous rapelle qu'une table est un objet mathématique dérivé de l'algèbre relationnelle et DOIT POSSEDER UNE CLEF. Une table sans clef est un fichier genre cobol.

Or les mécanismes de réplication imposent que votre modèle de données soit optimum :
repecter à la lettre l'aspect relationnel des tables en ayant aucun doublon et donc obligatoirement une clef (primaire)
Sans cela il est impossible de savoir quelle ligne est impacté par une mise à jour.
Or visiblement le script SQL que vous nous avez donné porte une clef écrite à l'arrachée sur la colonne rajoutée pour la réplication et ne peut EN AUCUN CAS être considéré comme la clef de votre table.

Comme je vous l'ai déjà dit à plusieurs reprise, la réplication nécessite un préalable qui est la connaissance de l'administration du SGBD SQL Server...
En outre, il n'y a pas de solution à votre problème sans commencer par modéliser votre base correctement.

Bref, il me semble nécessaire que vous vous formiez à :
a) la modélisation des données
b) l'administration de servers MS SQL
c) la réplication

Sans cela vous perdre du temps, vous en ferez perdre à votre entreprise (et le temps c'est de l'argent), et vous en faites actuellement perdre à vous répondre.

A +

[hellospinoza]

Habitué du forum (en tant que lecteur), je me suis senti obligé de créer un compte aujourd'hui.Non pour vous répondre emmanuel95 - débutant moi même en SQL je n'ai pas les compétences nécessaires - mais pour faire écho aux propos de Mr "SQLPro" qui m'ont pour ainsi dire choqué:
Cher monsieur , votre suffisance n'a d'égal que votre manque total de savoir vivre.Mais, pour qui vous prenez vous?
Quelle arrogance tenace vous permet de retorquer à quelqu'un qui cherche une solution à son problème :
1) d'aller se former,
2) de lui reprocher de vous faire perdre votre temps ?

Si chacun etait un érudit dans tous les domaines, il n'y aurait pas de forum.Point barre.Auprès de qui pourriez vous tenter de briller dès lors? En effet ,votre remarque déplacée et orpheline d'une quelquonque réflexion ne vise, en réalité,qu' à vous faire mousser par le truchement de quelques termes techniques disséminés ça et là qui , pensez vous, impressionneront la galerie et justifieront ce que vous croyez être votre réputation sur ce forum (tout est d'ailleurs dit dans le "Pro" de votre pseudo! Quelle humilité. On ne se refait pas).
S'agissant de "vous faire perdre votre temps" et pour faire simple je ne dirai qu'une chose : PASSEZ VOTRE CHEMIN, BON SANG! plutôt que de venir faire pipi dans les coins d'un post que vous considerez comme inutile et alimenté par des incapables.Modérer ne veux pas dire squatter.
Rassurez vous , vous trouverez quand même la gloire (à mes yeux mais pas pour les raisons que vous imaginez).Je n'avais jamais, jusqu'a ce jour, rencontré quelqu'un capable de perdre du temps à intervenir dans un post pour expliquer.....qu'on lui fait perdre son temps (modérateur ou pas).
Quant aux mièvres "leçons de vie" type: "le temps c'est de l'argent en entreprise".Quelle perspicacité! Reservez cela, par pitié, à vos enfants en bas âge (si par bonheur quelqu'un a accepté d'en faire avec vous) et fait nous l'économie de telles fulgurances à l'avenir qui ne font en rien progresser le shmilblick.

En bref, Si emmanuel95 doit se former sur SQL, vous avez bien plus fort à faire en allant vous former sur les relations sociales.Problème: je ne connais pas d'ecole à la hauteur du challenge que vous leur proposerez....

Ceci etant dit, j'aimerai savoir si vous accepteriez de venir parler de votre passion pour SQL lors de petits diner que nous organisons chaque jeudi entre amis?

A bientôt

PS:Aurez vous le courage de laisser ce post en ligne?

[emmanuel95]

Pour informations :
- La clé unique de la table existe, c'est le champ PRO_ID, on la voit dans le script SQL que j'ai laissé précédemment ([PRO_ID] [int] IDENTITY).
- Cette base a été mise en place par une des plus grosses SSII française (que je ne nommerais pas ici), et à mon avis ce ne sont pas des débutants en SQL. Ce sont eux qui ont mis en place cette base et cette réplication, je suis uniquement chargé de la maintenance 'fonctionnelle' de la base.
J'essayais juste de trouver une solution à mon 'petit' problème. Je connais très bien SQL Server, le transact-SQL et les services DTS, mais je ne connais pas très bien les réplications, n'ayant pas eu souvent l'occasion d'en manipuler.
Les gars de la SSII m'avaient dit au téléphone que je pouvais mettre à jour la base directement sur le serveur (update et insert), et que ces modifs seraient répercutées sur les postes client grace à la réplication.
J'espère qu'ils ne m'ont pas racontés des cracks au téléphone. Je leur ai demandé de l'aide sur ce problème, mais ils me répondent : "Devis", "Délai", etc... personnellement je pense qu'il suffit de peu de chose pour corriger ce problème, c'est pour ça que j'ai posté ici. Mais je ne pensais pas que ça déclencherai de telles foudres!

En tout cas merci pour votre attention.

Emmanuel.


P.S. : je suis allé voir les cours et didacticiel sur ce site, notamment sur l'administration SQL Server, mais je n'ai pas trouvé de cours sur la réplication avec fusion. Si vous savez où je peux trouver ça en ligne, ça m'interresse!

[kagemaru]

bonjour,

- La clé unique de la table existe, c'est le champ PRO_ID, on la voit dans le script SQL que j'ai laissé précédemment ([PRO_ID] [int] IDENTITY).

Oui, en effet


Cette erreur est rare car elle est spécifique à SQL Server Compact Edition (avec cet avant-propos dans la doc Microsoft :

Important :
Si vous rencontrez une erreur avec le préfixe « Erreur interne » lorsque vous utilisez SQL Server Compact Edition, réessayez l'opération, car l'erreur peut ne pas se reproduire. Si l'erreur réapparaît quand même, contactez immédiatement les services de support technique Microsoft. Les erreurs internes ne peuvent pas être résolues à l'aide des techniques de dépannages courantes.

)

SQL Compact étant bien moins présent que les versions Standard ou Entreprise, ce n'est pas évident d'avoir du retour.

Mettant en place et administrant régulièrement des réplications, cette erreur est inconnue.

Je vous recommande également la partie "Limites de la réplication sur du Compact Edition."

http://technet.microsoft.com/fr-fr/l.../ms171864.aspx

Essayez de voir s'il n'y a pas un dépassement de capacité à un moment donné côté machine Compact.

[SQLpro]

Code :

Habitué du forum (en tant que lecteur), je me suis senti obligé de créer un compte aujourd'hui.

Finalement mes polémiques servent à grossir le flux des impétrants de developpez.com... ;-)

Code :

...votre suffisance n'a d'égal que votre manque total de savoir vivre.

Je ne sais s'il s'agit de suffisance. Quant à mon manque de savoir vivre, je le revendique. Malgré sons aspect écrit, les forums sont du bavardage et je ne suis adepte ni du consensus mou, ni du politiquement correct. En outre il m'arrive de dire des conneries !

Code :

....tout est d'ailleurs dit dans le "Pro" de votre pseudo...

Pour information, ce pseudo vient de mon site SQLpro.developpez.com (et son mirroir sql.developpez;com) vieux maintenant de plus de 10 ans... Je l'ai créé parce que ce qui se disait à l'époque sur le langage SQL et la connaissance en matière de base de données, était tellement navrante que je voulais m'écarter des amateurs. D'ou le nom SQLpro !
Comme il se trouve au hit parade de google sur 300 millions de pages consacré à SQL, je pense avoir réussit ma mission...

Code :

vous avez bien plus fort à faire en allant vous former sur les relations sociales

Peine perdu... à 47 ans on ne se refait pas !

Code :

Ceci etant dit, j'aimerai savoir si vous accepteriez de venir parler de votre passion pour SQL lors de petits diner que nous organisons chaque jeudi entre amis?

Tout à fait volontier, même si vous voulez m'assassiner.... de reproches, critiques et autres verbiages.... comme vous l'avez sans doute compris, j'adore la contradiction !

Quelles sont vos conditions ???

A +

[emmanuel95]

Merci M. Emmanuel Torre, grace à votre lien sur les limites de SQL Server Compact Edition, j'ai trouvé une information interressante :

Contraintes NOT FOR REPLICATION
SQL Server Compact Edition ne prend pas en charge l'option NOT FOR REPLICATION. Ne créez pas de contraintes à l'aide de cette option. Si, dans une base de données, des contraintes possèdent l'option NOT FOR REPLICATION, supprimez-les, puis recréez-les. Si l'option NOT FOR REPLICATION est spécifiée, la contrainte est créée sur l'Abonné SQL Server Compact Edition, mais ne comprend pas la syntaxe NOT FOR REPLICATION.

Or, comme on le voit dans le script de création de la base que j'ai déjà posté, le champ ID de la table (le fameux PRO_ID) est créé en utilisant cette option "NOT FOR REPLICATION".

Je suppose que ça explique ce que j'ai constaté :
- Lors de ma première mise à jour de la base, je n'ai pas rajouté de ligne, je n'ai fait que des udates, et la réplication qui a suivi a fonctionné correctement.
- Lors de la mise à jour suivantes, par contre, j'ai lancé des updates mais aussi des INSERT, qui ont ajouté des PRO_ID dans la table. Or ce champ utilise NOT FOR REPLICATION, option non gérée par SQL Server Compact Edition, ce qui pourrait provoquer l'erreur 25001.

En supposant que ce soit bien ça le problème, comment puis-je le corriger?
Est ce que la suppression des lignes rajoutées sur le serveur permettrait d'avoir une réplication sans erreur? Et dans ce cas, comment ajouter des lignes sans provoquer cette erreur?
Apparemment, la description des limites de la Compact Edition propose de supprimer la contrainte NOT FOR REPLICATION et de la recréer. Je vais essayer de tester ça pour voir.

[kagemaru]

La clause not for replication indique à l'agent de fusion de ne pas incrémenter la valeur identity côté abonné. Le but est de pouvoir insérer des identifiants différents de chaque côté (par exemple, côté X, les id de 1 à 1000 et côté Y les id de 1001 à 2000).
Si la clause not for replication n'est pas mise, la valeur identity est incrémentée côté receveur.

Donc si la table Mds_Produit ne connait jamais d'insertions côté sql compact edition, vous pouvez supprimer cette clause.
Par contre s'il y a insertion d'un produit côté "Compact" il y a de forts risques de décalage des identifiants donc il faut bien s'assurer que les produits ne font que descendre vers les "Compact".
Si par exemple 2 machines "Compact" insèrent le produit id 8, côté Standard, il y aura 2 lignes, une à 8 et une à 9, compromettant la cohérence des données.

[emmanuel95]

J'ai eu confirmation : effectivement dans notre cas les postes clients (avec Compact Edition) ne font pas d'INSERT dans MDS_PRODUIT, donc ils ne créent pas de nouveaux PRO_ID.
Donc a priori je peux supprimer cette option NOT FOR REPLICATION.

Cette option est présente à plusieurs endroit :
- dans le script de création de la table

Code :

1
2
CREATE TABLE [dbo].[MDS_PRODUIT](
	[PRO_ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,

- et dans les contraintes créées par la réplication

Code :

1
2
3
ALTER TABLE [dbo].[MDS_PRODUIT]  WITH NOCHECK ADD  CONSTRAINT [repl_identity_range_AC5164F4_1F91_4B5F_ACDB_DAFB9AA662FB] CHECK NOT FOR REPLICATION (([PRO_ID]>(41492) AND [PRO_ID]<=(42492) OR [PRO_ID]>(42492) AND [PRO_ID]<=(43492)))
GO
ALTER TABLE [dbo].[MDS_PRODUIT] CHECK CONSTRAINT [repl_identity_range_AC5164F4_1F91_4B5F_ACDB_DAFB9AA662FB]

Donc je suppose que je dois supprimer ces deux contraintes, et modifier le champ PRO_ID.

Pouvez-vous me conseiller une méthode 'fiable' pour supprimer cette option sans supprimer de données, et surtout sans mettre 'en péril' la réplication?
Merci d'avance.

[kagemaru]

Normalement, cela se joue au niveau de l'agent de fusion qui va retirer tout seul les contraintes "not for repli" (côté base publiée) :

Code :

1
2
sp_changemergearticle 'mapub', 'matable', 'identityrangemanagementoption', 'none'
go

Il est impératif de tester ce cas sur un environnement de test (en créant une base bidon, 2 tables avec colonne identity (que aurez rempli pour vous retrouver dans le cas présent), une publication et un abonnement, dans la même base.

[emmanuel95]

Merci pour ces indications.
Bien sur pour l'instant je ne travaille que sur notre environnement de test, je ne ferai la modif en Prod qu'après avoir testé ma 'procedure' sur l'environnement de test.

J'ai trouvé aussi sur MSDN un article où ils expliquent qu'on peut désactiver la clé étrangère pour permettre la réplication :

Code :

1
2
3
4
-- Disable foreign key constraint
ALTER TABLE Orders
    NOCHECK CONSTRAINT 
        FK_Orders_Customers

Source : http://msdn.microsoft.com/msdnmag/is...lt.aspx?loc=fr

Mais dans mon cas la contrainte s'appelle "[repl_identity_range_AC5164F4_1F91_4B5F_ACDB_DAFB9AA662FB]", et je ne sais pas si je peux la désactiver comme on désactive une clé étrangère.
Je suppose qu'il vaut mieux utiliser la procédure stockée sp_changemergearticle ?

[emmanuel95]

J'ai essayé de lancer cette procédure stoquée

Code :

sp_changemergearticle 'MaPublication', '[dbo].[MDS_PRODUIT]', 'identityrangemanagementoption', 'none'

Et j'ai eu le message d'erreur suivant :

Code :

1
2
Msg 20027, Niveau 16, État 1, Procédure sp_changemergearticle, Ligne 224
L'article '[dbo].[MDS_PRODUIT]' n'existe pas.

Puis j'ai lu sur MSDN que l'option 'none' pour cette procédure stoquée "sp_changemergearticle" n'est disponible que pour les publications transactionnelles (je précise que ma base utilise une réplication de fusion).
(source : http://msdn2.microsoft.com/fr-fr/library/ms152543.aspx).

J'ai trouvé aussi la procédure suivante, et je crois qu'elle est addaptée à mon cas :

Pour désactiver une contrainte de validation lors de la réplication
1. Dans l'Explorateur d'objets, développez la table avec la contrainte que vous souhaitez modifier, puis développez le dossier Contraintes.
2. Cliquez avec le bouton droit sur la contrainte puis cliquez sur Conception (Modifier dans SP1 ou une version antérieure).
3. Dans la boîte de dialogue Contraintes de validation, sélectionnez la valeur Non pour Appliquer la réplication.
4. Cliquez sur Fermer.

Source : http://msdn2.microsoft.com/fr-fr/library/ms190235.aspx

Mais bon... vérification faite, pour la contrainte "[repl_identity_range_48FE8...]", l'option "Appliquer la réplication" est déjà à non. (essai manqué je suppose).

J'avoue que là je suis un peu bloqué...

[kagemaru]

Puis j'ai lu sur MSDN que l'option 'none' pour cette procédure stoquée "sp_changemergearticle" n'est disponible que pour les publications transactionnelles (je précise que ma base utilise une réplication de fusion).

sp_changemergearticle concerne exclusivement les réplication de fusion (merge en anglais).
Le message est simple : il ne trouve pas de table MDS_PRODUIT dans ta publication .... ou ton article est nommé différemment de la table (ce qui est possible mais plutôt rare ...). Je pense qu'il faut creuser de ce côté...

[emmanuel95]

J'ai aussi trouvé (toujours sur MSDN) la procédure stockée "sp_adjustpublisheridentityrange" (http://msdn2.microsoft.com/fr-fr/library/ms181527.aspx).
Je l'ai lancé sur ma publication, mais sans succès, la réplication échoue encore.

J'ai vérifié les propriétés de la publication, et l'article porte bien le même nom (MDS_PRODUIT).
Par contre, dans les propriétés de publication pour cet article, l'option "Direction de la synchronisation" est à "Bidirectionnel". Or dans mon cas, les abonnés ne modifient pas cette table : pour cette table je voudrais que les modifications aillent uniquement dans le sens serveur->abonné. Pour cela, est ce que je dois passer l'option "Direction de la synchronisation" à "Téléchargement seul pour l'Abonné, interdire les modifications de l'Abonné" ? Est ce que ça correspond à ce que je veux pour cette table?

[emmanuel95]

Merci! Effectivement, le nom de l'article n'est pas '[dbo].[MDS_PRODUIT]', mais 'MDS_PRODUIT' (sans les crochets et sans dbo... décidémment les habitudes ont la vie dure! )
Et du coup la commande sp_changemergearticle a réussi.

Par contre, la réplication ne fonctionne toujours pas.
(c'est vraiment galère ce truc! ça commence à me gaver ... du calme, reste zen manu, tu vas y arriver! en tout cas merci pour votre aide, sans ça je ne sais pas comment j'aurais fait!)

Autre piste : après la commande, j'ai recréé un script de create table pour cette table, juste pour voir : la contrainte "[repl_identity_range...]" a bien disparu, par contre j'ai toujours l'option "NOT FOR REPLICATION" sur le champ PRO_ID

Code :

1
2
CREATE TABLE [dbo].[MDS_PRODUIT](
	[PRO_ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,

Je suppose qu'il faut retirer cette option?

[kagemaru]

j'ai fait un petit test et effectivement la clause reste ... en fait c'est la gestion de la plage d'id qui est désactivée. La documentation n'est pas très claire à ce sujet.

Au final, tu est obligé de passer (comme souvent) par les scripts de réplication. Le seul moyen d'arrive à tes fins est de recréer la publication en générant le script SQL et d'éditer ce script afin de changer la partie identity dans le sp_addmergearticle :

Code :

sp_addmergearticle  ....... @identityrangemanagementoption = N'auto', @pub_identity_range = 100000, @identity_range = 10000, @threshold = 80 ...

en

Code :

sp_addmergearticle  ....... @identityrangemanagementoption = N'none' .......

Pour la partie abonnement, tu peux continuer avec l'interface graphique.

Et après la génération du snapshot, la table n'a plus le NOT FOR REPLI côté abonné...

[emmanuel95]

Le seul moyen d'arrive à tes fins est de recréer la publication...

Quels sont les risques de recréer la publication?
Je veux dire, en Prod j'ai des postes 'abonnés' qui tournent avec SQL Server Compact Edition depuis plusieurs mois, et je ne dois pas provoquer de pertes de données ni d'interruption du service (ou alors juste quelques minutes le temps de passer mes scripts).
Si je recrée la publication, est ce que ce sera transparent pour les abonnés? Je n'aurais pas d'opération à réaliser sur les postes des abonnés?
(je suppose que c'est ok mais il vaut mieux prévenir que guérir! )

Et puis, je ne sais pas encore comment on fait pour 'recréer la publication en générant le script SQL', mais bon je vais me renseigner et je devrais y arriver.

Et par curiosité : pourquoi ne pas tout simplement supprimer cette option NOT FOR REPLICATION ?

Code :

ALTER TABLE MDS_PRODUIT ALTER COLUMN PRO_ID DROP NOT FOR REPLICATION

[kagemaru]

Code :

Et par curiosité : pourquoi ne pas tout simplement supprimer cette OPTION NOT FOR REPLICATION ?

100% d'accord, en fait je ne pensais pas que l'on pouvait retirer cette option par un simple alter table