Merge Replication + Download Only Article + RowGuid
1 réponse
Laurent Bouyssou
Bonjour,
Pourquoi SQLServer 2005/2008 ajoute un RowGuid sur les tables choisies en
tant qu'article dans le cadre d'une replication de fusion et ce même si
l'article est marqué comme "Download-only to Subscriber, prohibit Subscriber
changes" ?
Ma compréhension est que la replication ajoute un RowGuid puisque les
données sont succeptibles d'êtres créés/Supprimées sur des serveurs
différents, pour garantir une unicité au niveau de la topologie
Publication/Subscriber.
Je ne vois donc pas l'intérêt du RowGuid dans ce cas de figure, des idées ?
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
Med Bouchenafa
C'est historique Comme son nom l'indique, la réplication par fusion était, á l'origine dédiée, á des cas où les données étaient censées être modifiées dans les deux parties. C’était le seul type de réplication qui permettait cela. La transactionnelle ne le permettait pas et l’option « avec mise á jour » n’est venue que beaucoup plus tard A l’origine la réplication unidirectionnelle était plutôt assurée par la réplication transactionnelle et celle-ci n’utilise pas de rowguid Il est vrai qu’aujourd’hui dans le cas d’une réplication unidirectionnelle, la colonne rowguid n’est pas vraiment fonctionnelle mais toutes les tables système utilisées par ce type de réplication, utilisent cette colonne. C’est ce qui explique son utilité
Bien cordialement Med Bouchenafa
"Laurent Bouyssou" <Laurent wrote in message news:
Bonjour,
Pourquoi SQLServer 2005/2008 ajoute un RowGuid sur les tables choisies en tant qu'article dans le cadre d'une replication de fusion et ce même si l'article est marqué comme "Download-only to Subscriber, prohibit Subscriber changes" ?
Ma compréhension est que la replication ajoute un RowGuid puisque les données sont succeptibles d'êtres créés/Supprimées sur des serveurs différents, pour garantir une unicité au niveau de la topologie Publication/Subscriber.
Je ne vois donc pas l'intérêt du RowGuid dans ce cas de figure, des idées ?
C'est historique
Comme son nom l'indique, la réplication par fusion était, á l'origine
dédiée, á des cas où les données étaient censées être modifiées dans les
deux parties.
C’était le seul type de réplication qui permettait cela. La transactionnelle
ne le permettait pas et l’option « avec mise á jour » n’est venue que
beaucoup plus tard
A l’origine la réplication unidirectionnelle était plutôt assurée par la
réplication transactionnelle et celle-ci n’utilise pas de rowguid
Il est vrai qu’aujourd’hui dans le cas d’une réplication unidirectionnelle,
la colonne rowguid n’est pas vraiment fonctionnelle mais toutes les tables
système utilisées par ce type de réplication, utilisent cette colonne.
C’est ce qui explique son utilité
Bien cordialement
Med Bouchenafa
"Laurent Bouyssou" <Laurent Bouyssou@discussions.microsoft.com> wrote in
message news:6762C8D9-B964-434F-8795-26CB18383FC3@microsoft.com...
Bonjour,
Pourquoi SQLServer 2005/2008 ajoute un RowGuid sur les tables choisies en
tant qu'article dans le cadre d'une replication de fusion et ce même si
l'article est marqué comme "Download-only to Subscriber, prohibit
Subscriber
changes" ?
Ma compréhension est que la replication ajoute un RowGuid puisque les
données sont succeptibles d'êtres créés/Supprimées sur des serveurs
différents, pour garantir une unicité au niveau de la topologie
Publication/Subscriber.
Je ne vois donc pas l'intérêt du RowGuid dans ce cas de figure, des idées
?
C'est historique Comme son nom l'indique, la réplication par fusion était, á l'origine dédiée, á des cas où les données étaient censées être modifiées dans les deux parties. C’était le seul type de réplication qui permettait cela. La transactionnelle ne le permettait pas et l’option « avec mise á jour » n’est venue que beaucoup plus tard A l’origine la réplication unidirectionnelle était plutôt assurée par la réplication transactionnelle et celle-ci n’utilise pas de rowguid Il est vrai qu’aujourd’hui dans le cas d’une réplication unidirectionnelle, la colonne rowguid n’est pas vraiment fonctionnelle mais toutes les tables système utilisées par ce type de réplication, utilisent cette colonne. C’est ce qui explique son utilité
Bien cordialement Med Bouchenafa
"Laurent Bouyssou" <Laurent wrote in message news:
Bonjour,
Pourquoi SQLServer 2005/2008 ajoute un RowGuid sur les tables choisies en tant qu'article dans le cadre d'une replication de fusion et ce même si l'article est marqué comme "Download-only to Subscriber, prohibit Subscriber changes" ?
Ma compréhension est que la replication ajoute un RowGuid puisque les données sont succeptibles d'êtres créés/Supprimées sur des serveurs différents, pour garantir une unicité au niveau de la topologie Publication/Subscriber.
Je ne vois donc pas l'intérêt du RowGuid dans ce cas de figure, des idées ?