[SQL Server 2005 Std] Pb de Réplication (IDENTITY)

Peck777 · 28/06/2006, 12h45

Bonjour !

J'ai un problème dans ma réplication transactionnelle avec mise à jour: j'explique en essayant d'être le plus clair possible.

J'ai deux serveurs S1 et S2 en SQL 2K5 Std. le distributeur et le publicateur est S1 et le seul abonné est S2.
La réplication tourne correctment depuis 1 mois, mais sur une table j'ai un conflit à cause de la colonne IDENTITY.
Cette table est une table de traçabililté qui enregistre les mouvements insert, update et delete via des triggers sur d'autres tables... bref...

S1 et S2 écrivent leurs propres lignes dans le table de traça, et il me faut cette colonne IDENTITY à cause d'éventuels doublons.
Sauf qu'avant la réplication, cette colonne avait NOT FOR REPLICATION à false, et elle est passer à true lors de la création de la publication. MAIS sur la table de S2, elle est restée à false !!!!! donc problème.

Que faire ? et surtout que dois-je appliquer à NOT FOR REPLICATION sur S1 et S2 ? pour que les numéros uniques générés ne se chevauchent pas.

Merci d'avance pour vos lumières

Peck777

SQLpro · 29/06/2006, 08h41

Oui, vous DEVEZ placer les colonnes pourvues de l'attribut IDENTITY à NOT FOR REPLICATION pour les deux tables.

A +

Peck777 · 29/06/2006, 10h32

Même si cette colonne IDENTITY fait partie de la clé primaire composée ?

Merci pour ta réponse

28/06/2006, 12h45	#1
Peck777 Membre à l'essai Inscription : janvier 2006 Messages : 57 Détails du profil Informations forums : Inscription : janvier 2006 Messages : 57 Points : 22 Points : 22	[SQL Server 2005 Std] Pb de Réplication (IDENTITY) Bonjour ! J'ai un problème dans ma réplication transactionnelle avec mise à jour: j'explique en essayant d'être le plus clair possible. J'ai deux serveurs S1 et S2 en SQL 2K5 Std. le distributeur et le publicateur est S1 et le seul abonné est S2. La réplication tourne correctment depuis 1 mois, mais sur une table j'ai un conflit à cause de la colonne IDENTITY. Cette table est une table de traçabililté qui enregistre les mouvements insert, update et delete via des triggers sur d'autres tables... bref... S1 et S2 écrivent leurs propres lignes dans le table de traça, et il me faut cette colonne IDENTITY à cause d'éventuels doublons. Sauf qu'avant la réplication, cette colonne avait NOT FOR REPLICATION à false, et elle est passer à true lors de la création de la publication. MAIS sur la table de S2, elle est restée à false !!!!! donc problème. Que faire ? et surtout que dois-je appliquer à NOT FOR REPLICATION sur S1 et S2 ? pour que les numéros uniques générés ne se chevauchent pas. Merci d'avance pour vos lumières Peck777
	00

29/06/2006, 08h41	#2
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 791 Points : 17 791	Oui, vous DEVEZ placer les colonnes pourvues de l'attribut IDENTITY à NOT FOR REPLICATION pour les deux tables. A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

29/06/2006, 10h32	#3
Peck777 Membre à l'essai Inscription : janvier 2006 Messages : 57 Détails du profil Informations forums : Inscription : janvier 2006 Messages : 57 Points : 22 Points : 22	Même si cette colonne IDENTITY fait partie de la clé primaire composée ? Merci pour ta réponse
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email