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
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
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
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 ***********************
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 ***********************
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 ***********************
>
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 ***********************
>