Pourquoi sp_adjustpublisheridentityrange

Le
U34
Bonjour,

Nous utilisons SQL Serveur 2005 en fusion de réplication
sur des portables équipés de SQL Express.

Voici le message apparu hier sur un programme qui utilise la base de
donnée à partir du serveur :

L'instruction INSERT à échoué, ca elle était en conflit avec une
contrainte de vérification de plage d'identité dans la base de Données
'DON1', table répliquée 'dbo.ECR1', column 'IDECR'. Si la colonne
identité est gérée automatiquement par la réplication, mettez à jour la
plage comme suit : pour les serveur de publication, exécutez
sp_adjustpublisheridentityrange ; pour l'abonné, éxécutez l'Agent de
distribution ou l'agent de fusion.

J'ai donc éxécuté sp_adjustpublisheridentityrange @Nom_Publication sur
le serveur de publication et tout est rentré dans l'ordre.

Mais enfin, je ne sais pas Pourquoi j'ai éxécuté cette commande et que
fait-elle exactement ?

merci
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred BROUARD
Le #11840141
U34 a écrit :
Bonjour,

Nous utilisons SQL Serveur 2005 en fusion de réplication
sur des portables équipés de SQL Express.

Voici le message apparu hier sur un programme qui utilise la base de
donnée à partir du serveur :

L'instruction INSERT à échoué, ca elle était en conflit avec une
contrainte de vérification de plage d'identité dans la base de Données
'DON1', table répliquée 'dbo.ECR1', column 'IDECR'. Si la colonne
identité est gérée automatiquement par la réplication, mettez à jour la
plage comme suit : pour les serveur de publication, exécutez
sp_adjustpublisheridentityrange ; pour l'abonné, éxécutez l'Agent de
distribution ou l'agent de fusion.

J'ai donc éxécuté sp_adjustpublisheridentityrange @Nom_Publication sur
le serveur de publication et tout est rentré dans l'ordre.

Mais enfin, je ne sais pas Pourquoi j'ai éxécuté cette commande et que
fait-elle exactement ?

merci



vous avez eu un recouvrement des clefs auto incrémentées. Lorsque vous
avez une réplication de fusion (a éviter si possible) il faut que les
clef auto incrémentées soient prises sans recouvrement entre les tables
des différentes sources. Visiblement la plage allouée n'était pas
suffisante et cela SQL Server ne peut pas le deviner.
La réplication de fusion oblige à une administration lourde car il y
aura toujours des conflist et donc des possibilité d'incohérence.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
U34
Le #11840041
Merci de votre réponse.
cela fait longtemps que je fais de la fusion de réplication (6 ans). Je n'ai
pas d'autres choix. ce sont des portables autonomes qui ont aussi une partie
de la base de données et mettent à jour des enregistrements.

Ce message peut-il se reproduire ?

Cordialement

Fred BROUARD a écrit :

U34 a écrit :
> Bonjour,
>
> Nous utilisons SQL Serveur 2005 en fusion de réplication
> sur des portables équipés de SQL Express.
>
> Voici le message apparu hier sur un programme qui utilise la base de
> donnée à partir du serveur :
>
> L'instruction INSERT à échoué, ca elle était en conflit avec une
> contrainte de vérification de plage d'identité dans la base de Données
> 'DON1', table répliquée 'dbo.ECR1', column 'IDECR'. Si la colonne
> identité est gérée automatiquement par la réplication, mettez à jour la
> plage comme suit : pour les serveur de publication, exécutez
> sp_adjustpublisheridentityrange ; pour l'abonné, éxécutez l'Agent de
> distribution ou l'agent de fusion.
>
> J'ai donc éxécuté sp_adjustpublisheridentityrange @Nom_Publication sur
> le serveur de publication et tout est rentré dans l'ordre.
>
> Mais enfin, je ne sais pas Pourquoi j'ai éxécuté cette commande et que
> fait-elle exactement ?
>
> merci
>
vous avez eu un recouvrement des clefs auto incrémentées. Lorsque vous
avez une réplication de fusion (a éviter si possible) il faut que les
clef auto incrémentées soient prises sans recouvrement entre les tables
des différentes sources. Visiblement la plage allouée n'était pas
suffisante et cela SQL Server ne peut pas le deviner.
La réplication de fusion oblige à une administration lourde car il y
aura toujours des conflist et donc des possibilité d'incohérence.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************


bruno reiter
Le #11840021
A mon avis, il faut éviter d'utiliser une autoident en fusion, il faut dans
ce cas utiliser un id + un code site ou computer pour éviter le
chevauchement de clés.

br

"U34" news:
Merci de votre réponse.
cela fait longtemps que je fais de la fusion de réplication (6 ans). Je
n'ai
pas d'autres choix. ce sont des portables autonomes qui ont aussi une
partie
de la base de données et mettent à jour des enregistrements.

Ce message peut-il se reproduire ?

Cordialement

Fred BROUARD a écrit :

U34 a écrit :
> Bonjour,
>
> Nous utilisons SQL Serveur 2005 en fusion de réplication
> sur des portables équipés de SQL Express.
>
> Voici le message apparu hier sur un programme qui utilise la base de
> donnée à partir du serveur :
>
> L'instruction INSERT à échoué, ca elle était en conflit avec une
> contrainte de vérification de plage d'identité dans la base de Données
> 'DON1', table répliquée 'dbo.ECR1', column 'IDECR'. Si la colonne
> identité est gérée automatiquement par la réplication, mettez à jour la
> plage comme suit : pour les serveur de publication, exécutez
> sp_adjustpublisheridentityrange ; pour l'abonné, éxécutez l'Agent de
> distribution ou l'agent de fusion.
>
> J'ai donc éxécuté sp_adjustpublisheridentityrange @Nom_Publication sur
> le serveur de publication et tout est rentré dans l'ordre.
>
> Mais enfin, je ne sais pas Pourquoi j'ai éxécuté cette commande et que
> fait-elle exactement ?
>
> merci
>
vous avez eu un recouvrement des clefs auto incrémentées. Lorsque vous
avez une réplication de fusion (a éviter si possible) il faut que les
clef auto incrémentées soient prises sans recouvrement entre les tables
des différentes sources. Visiblement la plage allouée n'était pas
suffisante et cela SQL Server ne peut pas le deviner.
La réplication de fusion oblige à une administration lourde car il y
aura toujours des conflist et donc des possibilité d'incohérence.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************





U34
Le #11839921
Bonjour,
C'est exactement ce que j'ai fait.
La pk = Colonne id(Compteur) + Zone Agence.

Ce que je n'arrive pas à comprendre c'est ce que fait la commande
sp_adjustpublisheridentityrange.
Son exécution a été instantanée. Que met-elle à jour exactement ?
Merci

bruno reiter a écrit :

A mon avis, il faut éviter d'utiliser une autoident en fusion, il faut dans
ce cas utiliser un id + un code site ou computer pour éviter le
chevauchement de clés.

br

"U34" news:
> Merci de votre réponse.
> cela fait longtemps que je fais de la fusion de réplication (6 ans). Je
> n'ai
> pas d'autres choix. ce sont des portables autonomes qui ont aussi une
> partie
> de la base de données et mettent à jour des enregistrements.
>
> Ce message peut-il se reproduire ?
>
> Cordialement
>
> Fred BROUARD a écrit :
>
>> U34 a écrit :
>> > Bonjour,
>> >
>> > Nous utilisons SQL Serveur 2005 en fusion de réplication
>> > sur des portables équipés de SQL Express.
>> >
>> > Voici le message apparu hier sur un programme qui utilise la base de
>> > donnée à partir du serveur :
>> >
>> > L'instruction INSERT à échoué, ca elle était en conflit avec une
>> > contrainte de vérification de plage d'identité dans la base de Données
>> > 'DON1', table répliquée 'dbo.ECR1', column 'IDECR'. Si la colonne
>> > identité est gérée automatiquement par la réplication, mettez à jour la
>> > plage comme suit : pour les serveur de publication, exécutez
>> > sp_adjustpublisheridentityrange ; pour l'abonné, éxécutez l'Agent de
>> > distribution ou l'agent de fusion.
>> >
>> > J'ai donc éxécuté sp_adjustpublisheridentityrange @Nom_Publication sur
>> > le serveur de publication et tout est rentré dans l'ordre.
>> >
>> > Mais enfin, je ne sais pas Pourquoi j'ai éxécuté cette commande et que
>> > fait-elle exactement ?
>> >
>> > merci
>> >
>> vous avez eu un recouvrement des clefs auto incrémentées. Lorsque vous
>> avez une réplication de fusion (a éviter si possible) il faut que les
>> clef auto incrémentées soient prises sans recouvrement entre les tables
>> des différentes sources. Visiblement la plage allouée n'était pas
>> suffisante et cela SQL Server ne peut pas le deviner.
>> La réplication de fusion oblige à une administration lourde car il y
>> aura toujours des conflist et donc des possibilité d'incohérence.
>>
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>


Publicité
Poster une réponse
Anonyme