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 ?
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
Fred BROUARD
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 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 ***********************
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
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 ***********************
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 ***********************
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
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" wrote in message 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 ***********************
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" <udaf34.noSpam@Wanadoo.fr> wrote in message
news:46078042.F2C6723B@Wanadoo.fr...
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 ***********************
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" wrote in message 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
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" wrote in message 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 *********************** >
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" <udaf34.noSpam@Wanadoo.fr> wrote in message
news:46078042.F2C6723B@Wanadoo.fr...
> 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 ***********************
>
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" wrote in message 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 *********************** >
