Bonjour à tous,
je test actuellement la réplication de fusion de sql server 2000 pour les
raisons suivantes :
- Replication multidirectionnelle entre l'éditeur et les abonnés.
- Toute modification sur un abonné est repliqué sur l'editeur puis sur
TOUS
les abonnés.
Je me trouve exactement dans ce cas de figure puisque mes abonnés (MSDE)
disposent de la même base de données en debut de journée, fonctionnement
de
manière autonomes la journée et fusionnent les modifications le soir.
Par mes tests, j'ajoute directement les données dans la même table pour
chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
moment disponible.
Le problème se situe au niveau de la fusion puisque des conflits
apparaissent avec des pertes de données.
Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
ajoute.
Les champs ajoutés devraient tous être visible sur l'éditeur et renvoyés
vers
tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
individuellement sur chaque MSDE.
De même, j'ai remarque que le nombre de conflits est different si les
abonnements sont simultanés ou différés de 2 min chacun par exemple.
Pourquoi ?
Pour note, la cle primaire de cette table est une cle auto. Lors de
l'ajout
d'un champ, ceux-ci ont le même ID sur les MSDEs.
Bonjour à tous,
je test actuellement la réplication de fusion de sql server 2000 pour les
raisons suivantes :
- Replication multidirectionnelle entre l'éditeur et les abonnés.
- Toute modification sur un abonné est repliqué sur l'editeur puis sur
TOUS
les abonnés.
Je me trouve exactement dans ce cas de figure puisque mes abonnés (MSDE)
disposent de la même base de données en debut de journée, fonctionnement
de
manière autonomes la journée et fusionnent les modifications le soir.
Par mes tests, j'ajoute directement les données dans la même table pour
chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
moment disponible.
Le problème se situe au niveau de la fusion puisque des conflits
apparaissent avec des pertes de données.
Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
ajoute.
Les champs ajoutés devraient tous être visible sur l'éditeur et renvoyés
vers
tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
individuellement sur chaque MSDE.
De même, j'ai remarque que le nombre de conflits est different si les
abonnements sont simultanés ou différés de 2 min chacun par exemple.
Pourquoi ?
Pour note, la cle primaire de cette table est une cle auto. Lors de
l'ajout
d'un champ, ceux-ci ont le même ID sur les MSDEs.
Bonjour à tous,
je test actuellement la réplication de fusion de sql server 2000 pour les
raisons suivantes :
- Replication multidirectionnelle entre l'éditeur et les abonnés.
- Toute modification sur un abonné est repliqué sur l'editeur puis sur
TOUS
les abonnés.
Je me trouve exactement dans ce cas de figure puisque mes abonnés (MSDE)
disposent de la même base de données en debut de journée, fonctionnement
de
manière autonomes la journée et fusionnent les modifications le soir.
Par mes tests, j'ajoute directement les données dans la même table pour
chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
moment disponible.
Le problème se situe au niveau de la fusion puisque des conflits
apparaissent avec des pertes de données.
Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
ajoute.
Les champs ajoutés devraient tous être visible sur l'éditeur et renvoyés
vers
tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
individuellement sur chaque MSDE.
De même, j'ai remarque que le nombre de conflits est different si les
abonnements sont simultanés ou différés de 2 min chacun par exemple.
Pourquoi ?
Pour note, la cle primaire de cette table est une cle auto. Lors de
l'ajout
d'un champ, ceux-ci ont le même ID sur les MSDEs.
quelle est la colonne qui fait l'unicité pour les insertions en fonction du
lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il est
normal que tu aies des problèmes.
br
"christophe" wrote in message
news:
> Bonjour à tous,
>
> je test actuellement la réplication de fusion de sql server 2000 pour les
> raisons suivantes :
> - Replication multidirectionnelle entre l'éditeur et les abonnés.
> - Toute modification sur un abonné est repliqué sur l'editeur puis sur
> TOUS
> les abonnés.
>
> Je me trouve exactement dans ce cas de figure puisque mes abonnés (MSDE)
> disposent de la même base de données en debut de journée, fonctionnement
> de
> manière autonomes la journée et fusionnent les modifications le soir.
>
> Par mes tests, j'ajoute directement les données dans la même table pour
> chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
> moment disponible.
>
> Le problème se situe au niveau de la fusion puisque des conflits
> apparaissent avec des pertes de données.
> Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
> ajoute.
> Les champs ajoutés devraient tous être visible sur l'éditeur et renvoyés
> vers
> tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
> individuellement sur chaque MSDE.
> De même, j'ai remarque que le nombre de conflits est different si les
> abonnements sont simultanés ou différés de 2 min chacun par exemple.
> Pourquoi ?
>
> Pour note, la cle primaire de cette table est une cle auto. Lors de
> l'ajout
> d'un champ, ceux-ci ont le même ID sur les MSDEs.
quelle est la colonne qui fait l'unicité pour les insertions en fonction du
lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il est
normal que tu aies des problèmes.
br
"christophe" <christophe@discussions.microsoft.com> wrote in message
news:396F1FA2-F829-4860-BC6B-0427211FD435@microsoft.com...
> Bonjour à tous,
>
> je test actuellement la réplication de fusion de sql server 2000 pour les
> raisons suivantes :
> - Replication multidirectionnelle entre l'éditeur et les abonnés.
> - Toute modification sur un abonné est repliqué sur l'editeur puis sur
> TOUS
> les abonnés.
>
> Je me trouve exactement dans ce cas de figure puisque mes abonnés (MSDE)
> disposent de la même base de données en debut de journée, fonctionnement
> de
> manière autonomes la journée et fusionnent les modifications le soir.
>
> Par mes tests, j'ajoute directement les données dans la même table pour
> chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
> moment disponible.
>
> Le problème se situe au niveau de la fusion puisque des conflits
> apparaissent avec des pertes de données.
> Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
> ajoute.
> Les champs ajoutés devraient tous être visible sur l'éditeur et renvoyés
> vers
> tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
> individuellement sur chaque MSDE.
> De même, j'ai remarque que le nombre de conflits est different si les
> abonnements sont simultanés ou différés de 2 min chacun par exemple.
> Pourquoi ?
>
> Pour note, la cle primaire de cette table est une cle auto. Lors de
> l'ajout
> d'un champ, ceux-ci ont le même ID sur les MSDEs.
quelle est la colonne qui fait l'unicité pour les insertions en fonction du
lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il est
normal que tu aies des problèmes.
br
"christophe" wrote in message
news:
> Bonjour à tous,
>
> je test actuellement la réplication de fusion de sql server 2000 pour les
> raisons suivantes :
> - Replication multidirectionnelle entre l'éditeur et les abonnés.
> - Toute modification sur un abonné est repliqué sur l'editeur puis sur
> TOUS
> les abonnés.
>
> Je me trouve exactement dans ce cas de figure puisque mes abonnés (MSDE)
> disposent de la même base de données en debut de journée, fonctionnement
> de
> manière autonomes la journée et fusionnent les modifications le soir.
>
> Par mes tests, j'ajoute directement les données dans la même table pour
> chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
> moment disponible.
>
> Le problème se situe au niveau de la fusion puisque des conflits
> apparaissent avec des pertes de données.
> Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
> ajoute.
> Les champs ajoutés devraient tous être visible sur l'éditeur et renvoyés
> vers
> tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
> individuellement sur chaque MSDE.
> De même, j'ai remarque que le nombre de conflits est different si les
> abonnements sont simultanés ou différés de 2 min chacun par exemple.
> Pourquoi ?
>
> Pour note, la cle primaire de cette table est une cle auto. Lors de
> l'ajout
> d'un champ, ceux-ci ont le même ID sur les MSDEs.
Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un numero
auto est utilise pour identifier les champs.
Est-il "obligatoire" de créer une colonne contenant un identifiant pour
chaque MSDE pour eviter les conflits.
Une question encore !
Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
pas
justement censer eviter ce genre de manipulation?
"bruno reiter [MVP]" a écrit :quelle est la colonne qui fait l'unicité pour les insertions en fonction
du
lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
est
normal que tu aies des problèmes.
br
"christophe" wrote in message
news:
> Bonjour à tous,
>
> je test actuellement la réplication de fusion de sql server 2000 pour
> les
> raisons suivantes :
> - Replication multidirectionnelle entre l'éditeur et les abonnés.
> - Toute modification sur un abonné est repliqué sur l'editeur puis sur
> TOUS
> les abonnés.
>
> Je me trouve exactement dans ce cas de figure puisque mes abonnés
> (MSDE)
> disposent de la même base de données en debut de journée,
> fonctionnement
> de
> manière autonomes la journée et fusionnent les modifications le soir.
>
> Par mes tests, j'ajoute directement les données dans la même table
> pour
> chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
> moment disponible.
>
> Le problème se situe au niveau de la fusion puisque des conflits
> apparaissent avec des pertes de données.
> Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
> ajoute.
> Les champs ajoutés devraient tous être visible sur l'éditeur et
> renvoyés
> vers
> tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
> individuellement sur chaque MSDE.
> De même, j'ai remarque que le nombre de conflits est different si les
> abonnements sont simultanés ou différés de 2 min chacun par exemple.
> Pourquoi ?
>
> Pour note, la cle primaire de cette table est une cle auto. Lors de
> l'ajout
> d'un champ, ceux-ci ont le même ID sur les MSDEs.
Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un numero
auto est utilise pour identifier les champs.
Est-il "obligatoire" de créer une colonne contenant un identifiant pour
chaque MSDE pour eviter les conflits.
Une question encore !
Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
pas
justement censer eviter ce genre de manipulation?
"bruno reiter [MVP]" a écrit :
quelle est la colonne qui fait l'unicité pour les insertions en fonction
du
lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
est
normal que tu aies des problèmes.
br
"christophe" <christophe@discussions.microsoft.com> wrote in message
news:396F1FA2-F829-4860-BC6B-0427211FD435@microsoft.com...
> Bonjour à tous,
>
> je test actuellement la réplication de fusion de sql server 2000 pour
> les
> raisons suivantes :
> - Replication multidirectionnelle entre l'éditeur et les abonnés.
> - Toute modification sur un abonné est repliqué sur l'editeur puis sur
> TOUS
> les abonnés.
>
> Je me trouve exactement dans ce cas de figure puisque mes abonnés
> (MSDE)
> disposent de la même base de données en debut de journée,
> fonctionnement
> de
> manière autonomes la journée et fusionnent les modifications le soir.
>
> Par mes tests, j'ajoute directement les données dans la même table
> pour
> chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
> moment disponible.
>
> Le problème se situe au niveau de la fusion puisque des conflits
> apparaissent avec des pertes de données.
> Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
> ajoute.
> Les champs ajoutés devraient tous être visible sur l'éditeur et
> renvoyés
> vers
> tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
> individuellement sur chaque MSDE.
> De même, j'ai remarque que le nombre de conflits est different si les
> abonnements sont simultanés ou différés de 2 min chacun par exemple.
> Pourquoi ?
>
> Pour note, la cle primaire de cette table est une cle auto. Lors de
> l'ajout
> d'un champ, ceux-ci ont le même ID sur les MSDEs.
Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un numero
auto est utilise pour identifier les champs.
Est-il "obligatoire" de créer une colonne contenant un identifiant pour
chaque MSDE pour eviter les conflits.
Une question encore !
Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
pas
justement censer eviter ce genre de manipulation?
"bruno reiter [MVP]" a écrit :quelle est la colonne qui fait l'unicité pour les insertions en fonction
du
lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
est
normal que tu aies des problèmes.
br
"christophe" wrote in message
news:
> Bonjour à tous,
>
> je test actuellement la réplication de fusion de sql server 2000 pour
> les
> raisons suivantes :
> - Replication multidirectionnelle entre l'éditeur et les abonnés.
> - Toute modification sur un abonné est repliqué sur l'editeur puis sur
> TOUS
> les abonnés.
>
> Je me trouve exactement dans ce cas de figure puisque mes abonnés
> (MSDE)
> disposent de la même base de données en debut de journée,
> fonctionnement
> de
> manière autonomes la journée et fusionnent les modifications le soir.
>
> Par mes tests, j'ajoute directement les données dans la même table
> pour
> chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
> moment disponible.
>
> Le problème se situe au niveau de la fusion puisque des conflits
> apparaissent avec des pertes de données.
> Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
> ajoute.
> Les champs ajoutés devraient tous être visible sur l'éditeur et
> renvoyés
> vers
> tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
> individuellement sur chaque MSDE.
> De même, j'ai remarque que le nombre de conflits est different si les
> abonnements sont simultanés ou différés de 2 min chacun par exemple.
> Pourquoi ?
>
> Pour note, la cle primaire de cette table est une cle auto. Lors de
> l'ajout
> d'un champ, ceux-ci ont le même ID sur les MSDEs.
inline
br
"christophe" wrote in message
news:
> Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un numero
> auto est utilise pour identifier les champs.
>
> Est-il "obligatoire" de créer une colonne contenant un identifiant pour
> chaque MSDE pour eviter les conflits.
ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>
> Une question encore !
> Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
> pas
> justement censer eviter ce genre de manipulation?
ce le serait dans le cas où elle est utilisée comme clé primaire.
>
> "bruno reiter [MVP]" a écrit :
>
>> quelle est la colonne qui fait l'unicité pour les insertions en fonction
>> du
>> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> est
>> normal que tu aies des problèmes.
>>
>> br
>>
>> "christophe" wrote in message
>> news:
>> > Bonjour à tous,
>> >
>> > je test actuellement la réplication de fusion de sql server 2000 pour
>> > les
>> > raisons suivantes :
>> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> > - Toute modification sur un abonné est repliqué sur l'editeur puis sur
>> > TOUS
>> > les abonnés.
>> >
>> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> > (MSDE)
>> > disposent de la même base de données en debut de journée,
>> > fonctionnement
>> > de
>> > manière autonomes la journée et fusionnent les modifications le soir.
>> >
>> > Par mes tests, j'ajoute directement les données dans la même table
>> > pour
>> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
>> > moment disponible.
>> >
>> > Le problème se situe au niveau de la fusion puisque des conflits
>> > apparaissent avec des pertes de données.
>> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> > ajoute.
>> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> > renvoyés
>> > vers
>> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> > individuellement sur chaque MSDE.
>> > De même, j'ai remarque que le nombre de conflits est different si les
>> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> > Pourquoi ?
>> >
>> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> > l'ajout
>> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>>
>>
>>
inline
br
"christophe" <christophe@discussions.microsoft.com> wrote in message
news:A4AB7D40-8B24-40D0-8083-CF18DD1D9BD4@microsoft.com...
> Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un numero
> auto est utilise pour identifier les champs.
>
> Est-il "obligatoire" de créer une colonne contenant un identifiant pour
> chaque MSDE pour eviter les conflits.
ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>
> Une question encore !
> Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
> pas
> justement censer eviter ce genre de manipulation?
ce le serait dans le cas où elle est utilisée comme clé primaire.
>
> "bruno reiter [MVP]" a écrit :
>
>> quelle est la colonne qui fait l'unicité pour les insertions en fonction
>> du
>> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> est
>> normal que tu aies des problèmes.
>>
>> br
>>
>> "christophe" <christophe@discussions.microsoft.com> wrote in message
>> news:396F1FA2-F829-4860-BC6B-0427211FD435@microsoft.com...
>> > Bonjour à tous,
>> >
>> > je test actuellement la réplication de fusion de sql server 2000 pour
>> > les
>> > raisons suivantes :
>> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> > - Toute modification sur un abonné est repliqué sur l'editeur puis sur
>> > TOUS
>> > les abonnés.
>> >
>> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> > (MSDE)
>> > disposent de la même base de données en debut de journée,
>> > fonctionnement
>> > de
>> > manière autonomes la journée et fusionnent les modifications le soir.
>> >
>> > Par mes tests, j'ajoute directement les données dans la même table
>> > pour
>> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
>> > moment disponible.
>> >
>> > Le problème se situe au niveau de la fusion puisque des conflits
>> > apparaissent avec des pertes de données.
>> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> > ajoute.
>> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> > renvoyés
>> > vers
>> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> > individuellement sur chaque MSDE.
>> > De même, j'ai remarque que le nombre de conflits est different si les
>> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> > Pourquoi ?
>> >
>> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> > l'ajout
>> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>>
>>
>>
inline
br
"christophe" wrote in message
news:
> Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un numero
> auto est utilise pour identifier les champs.
>
> Est-il "obligatoire" de créer une colonne contenant un identifiant pour
> chaque MSDE pour eviter les conflits.
ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>
> Une question encore !
> Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
> pas
> justement censer eviter ce genre de manipulation?
ce le serait dans le cas où elle est utilisée comme clé primaire.
>
> "bruno reiter [MVP]" a écrit :
>
>> quelle est la colonne qui fait l'unicité pour les insertions en fonction
>> du
>> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> est
>> normal que tu aies des problèmes.
>>
>> br
>>
>> "christophe" wrote in message
>> news:
>> > Bonjour à tous,
>> >
>> > je test actuellement la réplication de fusion de sql server 2000 pour
>> > les
>> > raisons suivantes :
>> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> > - Toute modification sur un abonné est repliqué sur l'editeur puis sur
>> > TOUS
>> > les abonnés.
>> >
>> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> > (MSDE)
>> > disposent de la même base de données en debut de journée,
>> > fonctionnement
>> > de
>> > manière autonomes la journée et fusionnent les modifications le soir.
>> >
>> > Par mes tests, j'ajoute directement les données dans la même table
>> > pour
>> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour le
>> > moment disponible.
>> >
>> > Le problème se situe au niveau de la fusion puisque des conflits
>> > apparaissent avec des pertes de données.
>> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> > ajoute.
>> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> > renvoyés
>> > vers
>> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> > individuellement sur chaque MSDE.
>> > De même, j'ai remarque que le nombre de conflits est different si les
>> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> > Pourquoi ?
>> >
>> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> > l'ajout
>> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>>
>>
>>
Je suis desolé mais je ne comprends cette réponse.
Pouvez vous m'expliquer plus en detail?
Merci
"bruno reiter [MVP]" a écrit :inline
br
"christophe" wrote in message
news:
> Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un
> numero
> auto est utilise pour identifier les champs.
>
> Est-il "obligatoire" de créer une colonne contenant un identifiant pour
> chaque MSDE pour eviter les conflits.
ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>
> Une question encore !
> Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
> pas
> justement censer eviter ce genre de manipulation?
ce le serait dans le cas où elle est utilisée comme clé primaire.
>
> "bruno reiter [MVP]" a écrit :
>
>> quelle est la colonne qui fait l'unicité pour les insertions en
>> fonction
>> du
>> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> est
>> normal que tu aies des problèmes.
>>
>> br
>>
>> "christophe" wrote in message
>> news:
>> > Bonjour à tous,
>> >
>> > je test actuellement la réplication de fusion de sql server 2000
>> > pour
>> > les
>> > raisons suivantes :
>> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> > - Toute modification sur un abonné est repliqué sur l'editeur puis
>> > sur
>> > TOUS
>> > les abonnés.
>> >
>> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> > (MSDE)
>> > disposent de la même base de données en debut de journée,
>> > fonctionnement
>> > de
>> > manière autonomes la journée et fusionnent les modifications le
>> > soir.
>> >
>> > Par mes tests, j'ajoute directement les données dans la même table
>> > pour
>> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour
>> > le
>> > moment disponible.
>> >
>> > Le problème se situe au niveau de la fusion puisque des conflits
>> > apparaissent avec des pertes de données.
>> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> > ajoute.
>> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> > renvoyés
>> > vers
>> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> > individuellement sur chaque MSDE.
>> > De même, j'ai remarque que le nombre de conflits est different si
>> > les
>> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> > Pourquoi ?
>> >
>> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> > l'ajout
>> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>>
>>
>>
Je suis desolé mais je ne comprends cette réponse.
Pouvez vous m'expliquer plus en detail?
Merci
"bruno reiter [MVP]" a écrit :
inline
br
"christophe" <christophe@discussions.microsoft.com> wrote in message
news:A4AB7D40-8B24-40D0-8083-CF18DD1D9BD4@microsoft.com...
> Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un
> numero
> auto est utilise pour identifier les champs.
>
> Est-il "obligatoire" de créer une colonne contenant un identifiant pour
> chaque MSDE pour eviter les conflits.
ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>
> Une question encore !
> Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
> pas
> justement censer eviter ce genre de manipulation?
ce le serait dans le cas où elle est utilisée comme clé primaire.
>
> "bruno reiter [MVP]" a écrit :
>
>> quelle est la colonne qui fait l'unicité pour les insertions en
>> fonction
>> du
>> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> est
>> normal que tu aies des problèmes.
>>
>> br
>>
>> "christophe" <christophe@discussions.microsoft.com> wrote in message
>> news:396F1FA2-F829-4860-BC6B-0427211FD435@microsoft.com...
>> > Bonjour à tous,
>> >
>> > je test actuellement la réplication de fusion de sql server 2000
>> > pour
>> > les
>> > raisons suivantes :
>> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> > - Toute modification sur un abonné est repliqué sur l'editeur puis
>> > sur
>> > TOUS
>> > les abonnés.
>> >
>> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> > (MSDE)
>> > disposent de la même base de données en debut de journée,
>> > fonctionnement
>> > de
>> > manière autonomes la journée et fusionnent les modifications le
>> > soir.
>> >
>> > Par mes tests, j'ajoute directement les données dans la même table
>> > pour
>> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour
>> > le
>> > moment disponible.
>> >
>> > Le problème se situe au niveau de la fusion puisque des conflits
>> > apparaissent avec des pertes de données.
>> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> > ajoute.
>> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> > renvoyés
>> > vers
>> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> > individuellement sur chaque MSDE.
>> > De même, j'ai remarque que le nombre de conflits est different si
>> > les
>> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> > Pourquoi ?
>> >
>> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> > l'ajout
>> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>>
>>
>>
Je suis desolé mais je ne comprends cette réponse.
Pouvez vous m'expliquer plus en detail?
Merci
"bruno reiter [MVP]" a écrit :inline
br
"christophe" wrote in message
news:
> Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un
> numero
> auto est utilise pour identifier les champs.
>
> Est-il "obligatoire" de créer une colonne contenant un identifiant pour
> chaque MSDE pour eviter les conflits.
ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>
> Une question encore !
> Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
> pas
> justement censer eviter ce genre de manipulation?
ce le serait dans le cas où elle est utilisée comme clé primaire.
>
> "bruno reiter [MVP]" a écrit :
>
>> quelle est la colonne qui fait l'unicité pour les insertions en
>> fonction
>> du
>> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> est
>> normal que tu aies des problèmes.
>>
>> br
>>
>> "christophe" wrote in message
>> news:
>> > Bonjour à tous,
>> >
>> > je test actuellement la réplication de fusion de sql server 2000
>> > pour
>> > les
>> > raisons suivantes :
>> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> > - Toute modification sur un abonné est repliqué sur l'editeur puis
>> > sur
>> > TOUS
>> > les abonnés.
>> >
>> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> > (MSDE)
>> > disposent de la même base de données en debut de journée,
>> > fonctionnement
>> > de
>> > manière autonomes la journée et fusionnent les modifications le
>> > soir.
>> >
>> > Par mes tests, j'ajoute directement les données dans la même table
>> > pour
>> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour
>> > le
>> > moment disponible.
>> >
>> > Le problème se situe au niveau de la fusion puisque des conflits
>> > apparaissent avec des pertes de données.
>> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> > ajoute.
>> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> > renvoyés
>> > vers
>> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> > individuellement sur chaque MSDE.
>> > De même, j'ai remarque que le nombre de conflits est different si
>> > les
>> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> > Pourquoi ?
>> >
>> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> > l'ajout
>> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>>
>>
>>
la colonne rowguidcol est le pivot de la repli fusion, elle permet de
repérer de manière unique un ligne participant à la fusion. Cependant elle
n'est pas forcément la clé primaire de la table, si elle l'était, il n'y
aurait pas de conflit.
Si elle n'est pas la clé primaire, une autre colonne (ou un groupe de
colonnes) sera clé primaire, pour fonctionner correctement en multi sites,
il faut que cette clé soit aussi unique non seulement sur le site mais aussi
globalement, donc qu'elle comporte une partie spécifique au site de
création. Sans doublon à la création et avec le moins possible de mises à
jour simultanées de la même ligne sur différents sites, il y a peu de
conflits.
br
"christophe" wrote in message
news:
> Je suis desolé mais je ne comprends cette réponse.
> Pouvez vous m'expliquer plus en detail?
>
> Merci
>
> "bruno reiter [MVP]" a écrit :
>
>> inline
>>
>> br
>>
>> "christophe" wrote in message
>> news:
>> > Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un
>> > numero
>> > auto est utilise pour identifier les champs.
>> >
>> > Est-il "obligatoire" de créer une colonne contenant un identifiant pour
>> > chaque MSDE pour eviter les conflits.
>> ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>>
>>
>> >
>> > Une question encore !
>> > Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
>> > pas
>> > justement censer eviter ce genre de manipulation?
>> ce le serait dans le cas où elle est utilisée comme clé primaire.
>>
>> >
>> > "bruno reiter [MVP]" a écrit :
>> >
>> >> quelle est la colonne qui fait l'unicité pour les insertions en
>> >> fonction
>> >> du
>> >> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> >> est
>> >> normal que tu aies des problèmes.
>> >>
>> >> br
>> >>
>> >> "christophe" wrote in message
>> >> news:
>> >> > Bonjour à tous,
>> >> >
>> >> > je test actuellement la réplication de fusion de sql server 2000
>> >> > pour
>> >> > les
>> >> > raisons suivantes :
>> >> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> >> > - Toute modification sur un abonné est repliqué sur l'editeur puis
>> >> > sur
>> >> > TOUS
>> >> > les abonnés.
>> >> >
>> >> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> >> > (MSDE)
>> >> > disposent de la même base de données en debut de journée,
>> >> > fonctionnement
>> >> > de
>> >> > manière autonomes la journée et fusionnent les modifications le
>> >> > soir.
>> >> >
>> >> > Par mes tests, j'ajoute directement les données dans la même table
>> >> > pour
>> >> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour
>> >> > le
>> >> > moment disponible.
>> >> >
>> >> > Le problème se situe au niveau de la fusion puisque des conflits
>> >> > apparaissent avec des pertes de données.
>> >> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> >> > ajoute.
>> >> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> >> > renvoyés
>> >> > vers
>> >> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> >> > individuellement sur chaque MSDE.
>> >> > De même, j'ai remarque que le nombre de conflits est different si
>> >> > les
>> >> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> >> > Pourquoi ?
>> >> >
>> >> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> >> > l'ajout
>> >> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>> >>
>> >>
>> >>
>>
>>
>>
la colonne rowguidcol est le pivot de la repli fusion, elle permet de
repérer de manière unique un ligne participant à la fusion. Cependant elle
n'est pas forcément la clé primaire de la table, si elle l'était, il n'y
aurait pas de conflit.
Si elle n'est pas la clé primaire, une autre colonne (ou un groupe de
colonnes) sera clé primaire, pour fonctionner correctement en multi sites,
il faut que cette clé soit aussi unique non seulement sur le site mais aussi
globalement, donc qu'elle comporte une partie spécifique au site de
création. Sans doublon à la création et avec le moins possible de mises à
jour simultanées de la même ligne sur différents sites, il y a peu de
conflits.
br
"christophe" <christophe@discussions.microsoft.com> wrote in message
news:8290DE7A-2242-46F0-9F65-036E624E27A4@microsoft.com...
> Je suis desolé mais je ne comprends cette réponse.
> Pouvez vous m'expliquer plus en detail?
>
> Merci
>
> "bruno reiter [MVP]" a écrit :
>
>> inline
>>
>> br
>>
>> "christophe" <christophe@discussions.microsoft.com> wrote in message
>> news:A4AB7D40-8B24-40D0-8083-CF18DD1D9BD4@microsoft.com...
>> > Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un
>> > numero
>> > auto est utilise pour identifier les champs.
>> >
>> > Est-il "obligatoire" de créer une colonne contenant un identifiant pour
>> > chaque MSDE pour eviter les conflits.
>> ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>>
>>
>> >
>> > Une question encore !
>> > Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
>> > pas
>> > justement censer eviter ce genre de manipulation?
>> ce le serait dans le cas où elle est utilisée comme clé primaire.
>>
>> >
>> > "bruno reiter [MVP]" a écrit :
>> >
>> >> quelle est la colonne qui fait l'unicité pour les insertions en
>> >> fonction
>> >> du
>> >> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> >> est
>> >> normal que tu aies des problèmes.
>> >>
>> >> br
>> >>
>> >> "christophe" <christophe@discussions.microsoft.com> wrote in message
>> >> news:396F1FA2-F829-4860-BC6B-0427211FD435@microsoft.com...
>> >> > Bonjour à tous,
>> >> >
>> >> > je test actuellement la réplication de fusion de sql server 2000
>> >> > pour
>> >> > les
>> >> > raisons suivantes :
>> >> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> >> > - Toute modification sur un abonné est repliqué sur l'editeur puis
>> >> > sur
>> >> > TOUS
>> >> > les abonnés.
>> >> >
>> >> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> >> > (MSDE)
>> >> > disposent de la même base de données en debut de journée,
>> >> > fonctionnement
>> >> > de
>> >> > manière autonomes la journée et fusionnent les modifications le
>> >> > soir.
>> >> >
>> >> > Par mes tests, j'ajoute directement les données dans la même table
>> >> > pour
>> >> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour
>> >> > le
>> >> > moment disponible.
>> >> >
>> >> > Le problème se situe au niveau de la fusion puisque des conflits
>> >> > apparaissent avec des pertes de données.
>> >> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> >> > ajoute.
>> >> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> >> > renvoyés
>> >> > vers
>> >> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> >> > individuellement sur chaque MSDE.
>> >> > De même, j'ai remarque que le nombre de conflits est different si
>> >> > les
>> >> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> >> > Pourquoi ?
>> >> >
>> >> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> >> > l'ajout
>> >> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>> >>
>> >>
>> >>
>>
>>
>>
la colonne rowguidcol est le pivot de la repli fusion, elle permet de
repérer de manière unique un ligne participant à la fusion. Cependant elle
n'est pas forcément la clé primaire de la table, si elle l'était, il n'y
aurait pas de conflit.
Si elle n'est pas la clé primaire, une autre colonne (ou un groupe de
colonnes) sera clé primaire, pour fonctionner correctement en multi sites,
il faut que cette clé soit aussi unique non seulement sur le site mais aussi
globalement, donc qu'elle comporte une partie spécifique au site de
création. Sans doublon à la création et avec le moins possible de mises à
jour simultanées de la même ligne sur différents sites, il y a peu de
conflits.
br
"christophe" wrote in message
news:
> Je suis desolé mais je ne comprends cette réponse.
> Pouvez vous m'expliquer plus en detail?
>
> Merci
>
> "bruno reiter [MVP]" a écrit :
>
>> inline
>>
>> br
>>
>> "christophe" wrote in message
>> news:
>> > Aucune colonne n'est utilisée pour différencier les MSDEs. Seul un
>> > numero
>> > auto est utilise pour identifier les champs.
>> >
>> > Est-il "obligatoire" de créer une colonne contenant un identifiant pour
>> > chaque MSDE pour eviter les conflits.
>> ce n'est pas obligatoire, mais indispensable pour éviter les conflits
>>
>>
>> >
>> > Une question encore !
>> > Dans ce cas precis, l'utilisation de la colonne Uniqueindentifier n'est
>> > pas
>> > justement censer eviter ce genre de manipulation?
>> ce le serait dans le cas où elle est utilisée comme clé primaire.
>>
>> >
>> > "bruno reiter [MVP]" a écrit :
>> >
>> >> quelle est la colonne qui fait l'unicité pour les insertions en
>> >> fonction
>> >> du
>> >> lieu d'insertion? s'il n'y en a pas et qu'il y a conflit sur la PK, il
>> >> est
>> >> normal que tu aies des problèmes.
>> >>
>> >> br
>> >>
>> >> "christophe" wrote in message
>> >> news:
>> >> > Bonjour à tous,
>> >> >
>> >> > je test actuellement la réplication de fusion de sql server 2000
>> >> > pour
>> >> > les
>> >> > raisons suivantes :
>> >> > - Replication multidirectionnelle entre l'éditeur et les abonnés.
>> >> > - Toute modification sur un abonné est repliqué sur l'editeur puis
>> >> > sur
>> >> > TOUS
>> >> > les abonnés.
>> >> >
>> >> > Je me trouve exactement dans ce cas de figure puisque mes abonnés
>> >> > (MSDE)
>> >> > disposent de la même base de données en debut de journée,
>> >> > fonctionnement
>> >> > de
>> >> > manière autonomes la journée et fusionnent les modifications le
>> >> > soir.
>> >> >
>> >> > Par mes tests, j'ajoute directement les données dans la même table
>> >> > pour
>> >> > chaque MSDE (ex: table toto ) puisque qu'aucune interface n'est pour
>> >> > le
>> >> > moment disponible.
>> >> >
>> >> > Le problème se situe au niveau de la fusion puisque des conflits
>> >> > apparaissent avec des pertes de données.
>> >> > Je ne comprends pas pourquoi car je ne modifie aucun champs mais en
>> >> > ajoute.
>> >> > Les champs ajoutés devraient tous être visible sur l'éditeur et
>> >> > renvoyés
>> >> > vers
>> >> > tous les abonnés. Ainsi chacun devrait posseder les champs ajoutés
>> >> > individuellement sur chaque MSDE.
>> >> > De même, j'ai remarque que le nombre de conflits est different si
>> >> > les
>> >> > abonnements sont simultanés ou différés de 2 min chacun par exemple.
>> >> > Pourquoi ?
>> >> >
>> >> > Pour note, la cle primaire de cette table est une cle auto. Lors de
>> >> > l'ajout
>> >> > d'un champ, ceux-ci ont le même ID sur les MSDEs.
>> >>
>> >>
>> >>
>>
>>
>>
