J'ai une application qui lors d'un procéssus de mise à jour supprime toutes
les données d'une sutructure entête/ligne et puis les récrées en mode insert
(ceci afin d'éviter la gestion des delete/insert/update) .
Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction sur
un site A, le site B (de façon aléatoire) n'a pas les même modification !!!!
Le processus de réplication ce déclenche bien mais une différence de données
est présente.
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
Pascal Deliot
Bonjour,
Ce genre de manipulation sur les données d'une table publier avec une réplication de fusion mène inévitablement à des problèmes de non convergence entre l'éditeur et les abonnée.
Ce genre de traitement est à proscrire impérativement si vous utiliser une publication de type fusion.
Deplus, même si ce traitement était fiable vous surchargé votre système de façon importante. Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en insérer 130, la réplication stockera et traitera 230 actions au lieu de 60 avec toute la gestion de conflit et les transfert de données associé. Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et 100 enregistrement inutile dans vos tables msmerge_contents, etc..
Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer proprement vos mises à jours (la meilleur métode).
"ANAIK AAB" a écrit dans le message de news: %
Bonjour,
J'ai une application qui lors d'un procéssus de mise à jour supprime toutes les données d'une sutructure entête/ligne et puis les récrées en mode insert (ceci afin d'éviter la gestion des delete/insert/update) . Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction sur un site A, le site B (de façon aléatoire) n'a pas les même modification !!!!
Le processus de réplication ce déclenche bien mais une différence de données est présente.
Est ce que quelqu'un à une solution ?
Merci.
Bonjour,
Ce genre de manipulation sur les données d'une table publier avec une
réplication de fusion mène inévitablement à des problèmes de non convergence
entre l'éditeur et les abonnée.
Ce genre de traitement est à proscrire impérativement si vous utiliser une
publication de type fusion.
Deplus, même si ce traitement était fiable vous surchargé votre système de
façon importante.
Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en
insérer 130, la réplication stockera et traitera 230 actions au lieu de 60
avec toute la gestion de conflit et les transfert de données associé.
Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et
100 enregistrement inutile dans vos tables msmerge_contents, etc..
Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer
proprement vos mises à jours (la meilleur métode).
"ANAIK AAB" <aabidi@anaik.fr> a écrit dans le message de news:
%23TJPJbknFHA.3608@TK2MSFTNGP15.phx.gbl...
Bonjour,
J'ai une application qui lors d'un procéssus de mise à jour supprime
toutes les données d'une sutructure entête/ligne et puis les récrées en
mode insert (ceci afin d'éviter la gestion des delete/insert/update) .
Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction sur
un site A, le site B (de façon aléatoire) n'a pas les même modification
!!!!
Le processus de réplication ce déclenche bien mais une différence de
données est présente.
Ce genre de manipulation sur les données d'une table publier avec une réplication de fusion mène inévitablement à des problèmes de non convergence entre l'éditeur et les abonnée.
Ce genre de traitement est à proscrire impérativement si vous utiliser une publication de type fusion.
Deplus, même si ce traitement était fiable vous surchargé votre système de façon importante. Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en insérer 130, la réplication stockera et traitera 230 actions au lieu de 60 avec toute la gestion de conflit et les transfert de données associé. Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et 100 enregistrement inutile dans vos tables msmerge_contents, etc..
Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer proprement vos mises à jours (la meilleur métode).
"ANAIK AAB" a écrit dans le message de news: %
Bonjour,
J'ai une application qui lors d'un procéssus de mise à jour supprime toutes les données d'une sutructure entête/ligne et puis les récrées en mode insert (ceci afin d'éviter la gestion des delete/insert/update) . Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction sur un site A, le site B (de façon aléatoire) n'a pas les même modification !!!!
Le processus de réplication ce déclenche bien mais une différence de données est présente.
Est ce que quelqu'un à une solution ?
Merci.
Pascal Deliot
Ooops...
Nouvelle version:
Bonjour,
Ce genre de manipulation sur les données d'une table publiée avec une réplication de fusion mène inévitablement à des problèmes de non convergence entre l'éditeur et les abonnées.
Ce genre de traitement est à proscrire impérativement si vous utilisez une publication de type fusion.
Deplus, même si ce traitement était fiable, vous surchargé votre système de façon importante. Si pour modifier 30 lignes, en ajouter 30 vous supprimez 100 lignes et en insérez 130, la réplication stockera et traitera 230 actions au lieu de 60 avec toute la gestion de conflit et les transferts de données associés. Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et 100 enregistrements inutiles dans vos tables msmerge_contents, etc.
Deux solutions, soit ne pas réutilisez le même ROWGUID (avec la complexité associée), soit gérer proprement vos mises à jours (la meilleur méthode).
Ooops...
Nouvelle version:
Bonjour,
Ce genre de manipulation sur les données d'une table publiée avec une
réplication de fusion mène inévitablement à des problèmes de non convergence
entre l'éditeur et les abonnées.
Ce genre de traitement est à proscrire impérativement si vous utilisez une
publication de type fusion.
Deplus, même si ce traitement était fiable, vous surchargé votre système de
façon importante.
Si pour modifier 30 lignes, en ajouter 30 vous supprimez 100 lignes et en
insérez 130, la réplication stockera et traitera 230 actions au lieu de 60
avec toute la gestion de conflit et les transferts de données associés.
Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone
et
100 enregistrements inutiles dans vos tables msmerge_contents, etc.
Deux solutions, soit ne pas réutilisez le même ROWGUID (avec la complexité
associée), soit gérer
proprement vos mises à jours (la meilleur méthode).
Ce genre de manipulation sur les données d'une table publiée avec une réplication de fusion mène inévitablement à des problèmes de non convergence entre l'éditeur et les abonnées.
Ce genre de traitement est à proscrire impérativement si vous utilisez une publication de type fusion.
Deplus, même si ce traitement était fiable, vous surchargé votre système de façon importante. Si pour modifier 30 lignes, en ajouter 30 vous supprimez 100 lignes et en insérez 130, la réplication stockera et traitera 230 actions au lieu de 60 avec toute la gestion de conflit et les transferts de données associés. Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et 100 enregistrements inutiles dans vos tables msmerge_contents, etc.
Deux solutions, soit ne pas réutilisez le même ROWGUID (avec la complexité associée), soit gérer proprement vos mises à jours (la meilleur méthode).
ANAIK AAB
Bonjour,
Je pense que la solution la plus simple à mettre en oeuvre est de changer les rowguid . Je voulais savoir et comprendre pourquoi (pour le future) lors d'une instruction de suppression puis d'une insertion de données dans la même transaction le mécanisme de réplication par fusion ne fonctionnement pas correctement. Est-ce un bug ou pas ? Dans tous les cas, je vous remercie de votre réactivité.
Merci
"Pascal Deliot" a écrit dans le message de news: %
Bonjour,
Ce genre de manipulation sur les données d'une table publier avec une réplication de fusion mène inévitablement à des problèmes de non convergence entre l'éditeur et les abonnée.
Ce genre de traitement est à proscrire impérativement si vous utiliser une publication de type fusion.
Deplus, même si ce traitement était fiable vous surchargé votre système de façon importante. Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en insérer 130, la réplication stockera et traitera 230 actions au lieu de 60 avec toute la gestion de conflit et les transfert de données associé. Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et 100 enregistrement inutile dans vos tables msmerge_contents, etc..
Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer proprement vos mises à jours (la meilleur métode).
"ANAIK AAB" a écrit dans le message de news: %
Bonjour,
J'ai une application qui lors d'un procéssus de mise à jour supprime toutes les données d'une sutructure entête/ligne et puis les récrées en mode insert (ceci afin d'éviter la gestion des delete/insert/update) . Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction sur un site A, le site B (de façon aléatoire) n'a pas les même modification !!!!
Le processus de réplication ce déclenche bien mais une différence de données est présente.
Est ce que quelqu'un à une solution ?
Merci.
Bonjour,
Je pense que la solution la plus simple à mettre en oeuvre est de changer
les rowguid .
Je voulais savoir et comprendre pourquoi (pour le future) lors d'une
instruction de suppression puis d'une insertion de données
dans la même transaction le mécanisme de réplication par fusion ne
fonctionnement pas correctement. Est-ce un bug ou pas ?
Dans tous les cas, je vous remercie de votre réactivité.
Merci
"Pascal Deliot" <pdeliot@microsoft.com> a écrit dans le message de news:
%23kN7CCynFHA.4012@TK2MSFTNGP09.phx.gbl...
Bonjour,
Ce genre de manipulation sur les données d'une table publier avec une
réplication de fusion mène inévitablement à des problèmes de non
convergence entre l'éditeur et les abonnée.
Ce genre de traitement est à proscrire impérativement si vous utiliser une
publication de type fusion.
Deplus, même si ce traitement était fiable vous surchargé votre système de
façon importante.
Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en
insérer 130, la réplication stockera et traitera 230 actions au lieu de 60
avec toute la gestion de conflit et les transfert de données associé.
Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone
et 100 enregistrement inutile dans vos tables msmerge_contents, etc..
Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer
proprement vos mises à jours (la meilleur métode).
"ANAIK AAB" <aabidi@anaik.fr> a écrit dans le message de news:
%23TJPJbknFHA.3608@TK2MSFTNGP15.phx.gbl...
Bonjour,
J'ai une application qui lors d'un procéssus de mise à jour supprime
toutes les données d'une sutructure entête/ligne et puis les récrées en
mode insert (ceci afin d'éviter la gestion des delete/insert/update) .
Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction
sur un site A, le site B (de façon aléatoire) n'a pas les même
modification !!!!
Le processus de réplication ce déclenche bien mais une différence de
données est présente.
Je pense que la solution la plus simple à mettre en oeuvre est de changer les rowguid . Je voulais savoir et comprendre pourquoi (pour le future) lors d'une instruction de suppression puis d'une insertion de données dans la même transaction le mécanisme de réplication par fusion ne fonctionnement pas correctement. Est-ce un bug ou pas ? Dans tous les cas, je vous remercie de votre réactivité.
Merci
"Pascal Deliot" a écrit dans le message de news: %
Bonjour,
Ce genre de manipulation sur les données d'une table publier avec une réplication de fusion mène inévitablement à des problèmes de non convergence entre l'éditeur et les abonnée.
Ce genre de traitement est à proscrire impérativement si vous utiliser une publication de type fusion.
Deplus, même si ce traitement était fiable vous surchargé votre système de façon importante. Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en insérer 130, la réplication stockera et traitera 230 actions au lieu de 60 avec toute la gestion de conflit et les transfert de données associé. Vous aurez 100 enregistrements inutiles dans vos tables msmerge_tombstone et 100 enregistrement inutile dans vos tables msmerge_contents, etc..
Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer proprement vos mises à jours (la meilleur métode).
"ANAIK AAB" a écrit dans le message de news: %
Bonjour,
J'ai une application qui lors d'un procéssus de mise à jour supprime toutes les données d'une sutructure entête/ligne et puis les récrées en mode insert (ceci afin d'éviter la gestion des delete/insert/update) . Pour les mises à jour de données nous conservons avec les mêmes ROWGUID.
J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction sur un site A, le site B (de façon aléatoire) n'a pas les même modification !!!!
Le processus de réplication ce déclenche bien mais une différence de données est présente.
Est ce que quelqu'un à une solution ?
Merci.
bruno reiter [MVP]
le problème en l'occurence est que la répli de fusion se base sur la colonne rowguidcol pour ses mises à jour, donc la réutilisation d'un meme guid (réputé unique normalement) met le bazar.
br
"ANAIK AAB" wrote in message news:
Bonjour,
Je pense que la solution la plus simple à mettre en oeuvre est de changer les rowguid . Je voulais savoir et comprendre pourquoi (pour le future) lors d'une instruction de suppression puis d'une insertion de données dans la même transaction le mécanisme de réplication par fusion ne fonctionnement pas correctement. Est-ce un bug ou pas ? Dans tous les cas, je vous remercie de votre réactivité.
Merci
"Pascal Deliot" a écrit dans le message de news: % > Bonjour, > > Ce genre de manipulation sur les données d'une table publier avec une > réplication de fusion mène inévitablement à des problèmes de non > convergence entre l'éditeur et les abonnée. > > Ce genre de traitement est à proscrire impérativement si vous utiliser
une
> publication de type fusion. > > Deplus, même si ce traitement était fiable vous surchargé votre système
de
> façon importante. > Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en > insérer 130, la réplication stockera et traitera 230 actions au lieu de
60
> avec toute la gestion de conflit et les transfert de données associé. > Vous aurez 100 enregistrements inutiles dans vos tables
msmerge_tombstone
> et 100 enregistrement inutile dans vos tables msmerge_contents, etc.. > > Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer > proprement vos mises à jours (la meilleur métode). > > > "ANAIK AAB" a écrit dans le message de news: > % >> Bonjour, >> >> J'ai une application qui lors d'un procéssus de mise à jour supprime >> toutes les données d'une sutructure entête/ligne et puis les récrées en >> mode insert (ceci afin d'éviter la gestion des delete/insert/update) . >> Pour les mises à jour de données nous conservons avec les mêmes
ROWGUID.
>> >> J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction >> sur un site A, le site B (de façon aléatoire) n'a pas les même >> modification !!!! >> >> Le processus de réplication ce déclenche bien mais une différence de >> données est présente. >> >> Est ce que quelqu'un à une solution ? >> >> Merci. >> >> >> > >
le problème en l'occurence est que la répli de fusion se base sur la colonne
rowguidcol pour ses mises à jour, donc la réutilisation d'un meme guid
(réputé unique normalement) met le bazar.
br
"ANAIK AAB" <aabidi@anaik.fr> wrote in message
news:eWIBIi9nFHA.1048@tk2msftngp13.phx.gbl...
Bonjour,
Je pense que la solution la plus simple à mettre en oeuvre est de changer
les rowguid .
Je voulais savoir et comprendre pourquoi (pour le future) lors d'une
instruction de suppression puis d'une insertion de données
dans la même transaction le mécanisme de réplication par fusion ne
fonctionnement pas correctement. Est-ce un bug ou pas ?
Dans tous les cas, je vous remercie de votre réactivité.
Merci
"Pascal Deliot" <pdeliot@microsoft.com> a écrit dans le message de news:
%23kN7CCynFHA.4012@TK2MSFTNGP09.phx.gbl...
> Bonjour,
>
> Ce genre de manipulation sur les données d'une table publier avec une
> réplication de fusion mène inévitablement à des problèmes de non
> convergence entre l'éditeur et les abonnée.
>
> Ce genre de traitement est à proscrire impérativement si vous utiliser
une
> publication de type fusion.
>
> Deplus, même si ce traitement était fiable vous surchargé votre système
de
> façon importante.
> Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en
> insérer 130, la réplication stockera et traitera 230 actions au lieu de
60
> avec toute la gestion de conflit et les transfert de données associé.
> Vous aurez 100 enregistrements inutiles dans vos tables
msmerge_tombstone
> et 100 enregistrement inutile dans vos tables msmerge_contents, etc..
>
> Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer
> proprement vos mises à jours (la meilleur métode).
>
>
> "ANAIK AAB" <aabidi@anaik.fr> a écrit dans le message de news:
> %23TJPJbknFHA.3608@TK2MSFTNGP15.phx.gbl...
>> Bonjour,
>>
>> J'ai une application qui lors d'un procéssus de mise à jour supprime
>> toutes les données d'une sutructure entête/ligne et puis les récrées en
>> mode insert (ceci afin d'éviter la gestion des delete/insert/update) .
>> Pour les mises à jour de données nous conservons avec les mêmes
ROWGUID.
>>
>> J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction
>> sur un site A, le site B (de façon aléatoire) n'a pas les même
>> modification !!!!
>>
>> Le processus de réplication ce déclenche bien mais une différence de
>> données est présente.
>>
>> Est ce que quelqu'un à une solution ?
>>
>> Merci.
>>
>>
>>
>
>
le problème en l'occurence est que la répli de fusion se base sur la colonne rowguidcol pour ses mises à jour, donc la réutilisation d'un meme guid (réputé unique normalement) met le bazar.
br
"ANAIK AAB" wrote in message news:
Bonjour,
Je pense que la solution la plus simple à mettre en oeuvre est de changer les rowguid . Je voulais savoir et comprendre pourquoi (pour le future) lors d'une instruction de suppression puis d'une insertion de données dans la même transaction le mécanisme de réplication par fusion ne fonctionnement pas correctement. Est-ce un bug ou pas ? Dans tous les cas, je vous remercie de votre réactivité.
Merci
"Pascal Deliot" a écrit dans le message de news: % > Bonjour, > > Ce genre de manipulation sur les données d'une table publier avec une > réplication de fusion mène inévitablement à des problèmes de non > convergence entre l'éditeur et les abonnée. > > Ce genre de traitement est à proscrire impérativement si vous utiliser
une
> publication de type fusion. > > Deplus, même si ce traitement était fiable vous surchargé votre système
de
> façon importante. > Si pour modifier 30 lignes en ajouter 30 vous supprimer 100 lignes et en > insérer 130, la réplication stockera et traitera 230 actions au lieu de
60
> avec toute la gestion de conflit et les transfert de données associé. > Vous aurez 100 enregistrements inutiles dans vos tables
msmerge_tombstone
> et 100 enregistrement inutile dans vos tables msmerge_contents, etc.. > > Deux solutions, soit ne réutilisez pas le même ROWGUID, soit gérer > proprement vos mises à jours (la meilleur métode). > > > "ANAIK AAB" a écrit dans le message de news: > % >> Bonjour, >> >> J'ai une application qui lors d'un procéssus de mise à jour supprime >> toutes les données d'une sutructure entête/ligne et puis les récrées en >> mode insert (ceci afin d'éviter la gestion des delete/insert/update) . >> Pour les mises à jour de données nous conservons avec les mêmes
ROWGUID.
>> >> J'ai une Réplication de fusion entre 4 sites et lors d'une modifiction >> sur un site A, le site B (de façon aléatoire) n'a pas les même >> modification !!!! >> >> Le processus de réplication ce déclenche bien mais une différence de >> données est présente. >> >> Est ce que quelqu'un à une solution ? >> >> Merci. >> >> >> > >
