Bonjour à tous,
J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
Pour synchroniser tout cela, je suis en train de tester la réplication
par fusion. ça a effectivement l'air de marcher mais je souhaiterais
en savoir plus quant aux mises à jour de structure de base de
données.
1/ Que peut gérer exactement la réplication: ajout/suppression de
champs, ajout/suppression de tables ,...
2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
table, comment faire ? faut il supprimer la publication en cours, faire
les modifs, recréer la publication ?? Refaire une capture instantanée
?
3/ Apparemment lorsque je fais une capture instantannée, la bas de
données abonnée devient l'image exacte de la base de données serveur
mais perd les modifications sur la base de l'abonné qui n'avaient pas
été synchronisées? Est ce bien le rôle d'une capture ?
4/ En règle général, le retour de l'utilisation de la réplication
par fusion est il bon ?
5/ l'activeX gérant la réplication est il intéressant ?
Merci par avance
Bonjour à tous,
J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
Pour synchroniser tout cela, je suis en train de tester la réplication
par fusion. ça a effectivement l'air de marcher mais je souhaiterais
en savoir plus quant aux mises à jour de structure de base de
données.
1/ Que peut gérer exactement la réplication: ajout/suppression de
champs, ajout/suppression de tables ,...
2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
table, comment faire ? faut il supprimer la publication en cours, faire
les modifs, recréer la publication ?? Refaire une capture instantanée
?
3/ Apparemment lorsque je fais une capture instantannée, la bas de
données abonnée devient l'image exacte de la base de données serveur
mais perd les modifications sur la base de l'abonné qui n'avaient pas
été synchronisées? Est ce bien le rôle d'une capture ?
4/ En règle général, le retour de l'utilisation de la réplication
par fusion est il bon ?
5/ l'activeX gérant la réplication est il intéressant ?
Merci par avance
Bonjour à tous,
J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
Pour synchroniser tout cela, je suis en train de tester la réplication
par fusion. ça a effectivement l'air de marcher mais je souhaiterais
en savoir plus quant aux mises à jour de structure de base de
données.
1/ Que peut gérer exactement la réplication: ajout/suppression de
champs, ajout/suppression de tables ,...
2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
table, comment faire ? faut il supprimer la publication en cours, faire
les modifs, recréer la publication ?? Refaire une capture instantanée
?
3/ Apparemment lorsque je fais une capture instantannée, la bas de
données abonnée devient l'image exacte de la base de données serveur
mais perd les modifications sur la base de l'abonné qui n'avaient pas
été synchronisées? Est ce bien le rôle d'une capture ?
4/ En règle général, le retour de l'utilisation de la réplication
par fusion est il bon ?
5/ l'activeX gérant la réplication est il intéressant ?
Merci par avance
>>5/ l'activeX gérant la réplication est il intéressant ?
>>5/ l'activeX gérant la réplication est il intéressant ?
>>5/ l'activeX gérant la réplication est il intéressant ?
Bonjour,
En effet, les modifications de structure ne sont pas répliquées de ma nière
automatique sans repasser par une capture instantanée.
Pour ce qui est de la capture instantanée, vous pouvez spécifier, dan s les
options de la publication, si les données existantes, tables, procédu res ...
sont écrasées ou conservées. Par contre, si vous ne souhaitez pas écraser les
données existantes, celles-ci ne seront pas pour autant répliquées vers le
serveur central.
De manière générale, la réplication par fusion est une très bon ne chose tant
qu'elle est utilisée de manière pertinente. De plus, il n'est pas ais ée de
mettre en place ce type de réplication avec la gestion des conflits de
synchronisation des données.
Pour la notion d'ActiveX permettant le traitement des données lors de la
réplication, il est fortement conseillé de les utiliser qu'en cas o ù il ne
serait pas possible de le faire au travers des procédures stockées de la
réplication. En effet, les ActiveX ont des impacts énormes sur les
performances de votre réplication.
Pour infos, il est tout à fait possible de fournir ces propres procéd ures
stockées de réplication plutôt que celle générée lors de la c réation de la
réplication. Il suffit pour cela de spécifier leur nom au niveau des options
de la publication.
--
arno - http://www.dotnetguru2.org/acleret/
"SCJ" a écrit :
> Bonjour à tous,
>
> J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
> Pour synchroniser tout cela, je suis en train de tester la réplication
> par fusion. ça a effectivement l'air de marcher mais je souhaiterais
> en savoir plus quant aux mises à jour de structure de base de
> données.
> 1/ Que peut gérer exactement la réplication: ajout/suppression de
> champs, ajout/suppression de tables ,...
> 2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
> table, comment faire ? faut il supprimer la publication en cours, faire
> les modifs, recréer la publication ?? Refaire une capture instantan ée
> ?
> 3/ Apparemment lorsque je fais une capture instantannée, la bas de
> données abonnée devient l'image exacte de la base de données serv eur
> mais perd les modifications sur la base de l'abonné qui n'avaient pas
> été synchronisées? Est ce bien le rôle d'une capture ?
> 4/ En règle général, le retour de l'utilisation de la réplicati on
> par fusion est il bon ?
> 5/ l'activeX gérant la réplication est il intéressant ?
> Merci par avance
>
>
Bonjour,
En effet, les modifications de structure ne sont pas répliquées de ma nière
automatique sans repasser par une capture instantanée.
Pour ce qui est de la capture instantanée, vous pouvez spécifier, dan s les
options de la publication, si les données existantes, tables, procédu res ...
sont écrasées ou conservées. Par contre, si vous ne souhaitez pas écraser les
données existantes, celles-ci ne seront pas pour autant répliquées vers le
serveur central.
De manière générale, la réplication par fusion est une très bon ne chose tant
qu'elle est utilisée de manière pertinente. De plus, il n'est pas ais ée de
mettre en place ce type de réplication avec la gestion des conflits de
synchronisation des données.
Pour la notion d'ActiveX permettant le traitement des données lors de la
réplication, il est fortement conseillé de les utiliser qu'en cas o ù il ne
serait pas possible de le faire au travers des procédures stockées de la
réplication. En effet, les ActiveX ont des impacts énormes sur les
performances de votre réplication.
Pour infos, il est tout à fait possible de fournir ces propres procéd ures
stockées de réplication plutôt que celle générée lors de la c réation de la
réplication. Il suffit pour cela de spécifier leur nom au niveau des options
de la publication.
--
arno - http://www.dotnetguru2.org/acleret/
"SCJ" a écrit :
> Bonjour à tous,
>
> J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
> Pour synchroniser tout cela, je suis en train de tester la réplication
> par fusion. ça a effectivement l'air de marcher mais je souhaiterais
> en savoir plus quant aux mises à jour de structure de base de
> données.
> 1/ Que peut gérer exactement la réplication: ajout/suppression de
> champs, ajout/suppression de tables ,...
> 2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
> table, comment faire ? faut il supprimer la publication en cours, faire
> les modifs, recréer la publication ?? Refaire une capture instantan ée
> ?
> 3/ Apparemment lorsque je fais une capture instantannée, la bas de
> données abonnée devient l'image exacte de la base de données serv eur
> mais perd les modifications sur la base de l'abonné qui n'avaient pas
> été synchronisées? Est ce bien le rôle d'une capture ?
> 4/ En règle général, le retour de l'utilisation de la réplicati on
> par fusion est il bon ?
> 5/ l'activeX gérant la réplication est il intéressant ?
> Merci par avance
>
>
Bonjour,
En effet, les modifications de structure ne sont pas répliquées de ma nière
automatique sans repasser par une capture instantanée.
Pour ce qui est de la capture instantanée, vous pouvez spécifier, dan s les
options de la publication, si les données existantes, tables, procédu res ...
sont écrasées ou conservées. Par contre, si vous ne souhaitez pas écraser les
données existantes, celles-ci ne seront pas pour autant répliquées vers le
serveur central.
De manière générale, la réplication par fusion est une très bon ne chose tant
qu'elle est utilisée de manière pertinente. De plus, il n'est pas ais ée de
mettre en place ce type de réplication avec la gestion des conflits de
synchronisation des données.
Pour la notion d'ActiveX permettant le traitement des données lors de la
réplication, il est fortement conseillé de les utiliser qu'en cas o ù il ne
serait pas possible de le faire au travers des procédures stockées de la
réplication. En effet, les ActiveX ont des impacts énormes sur les
performances de votre réplication.
Pour infos, il est tout à fait possible de fournir ces propres procéd ures
stockées de réplication plutôt que celle générée lors de la c réation de la
réplication. Il suffit pour cela de spécifier leur nom au niveau des options
de la publication.
--
arno - http://www.dotnetguru2.org/acleret/
"SCJ" a écrit :
> Bonjour à tous,
>
> J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
> Pour synchroniser tout cela, je suis en train de tester la réplication
> par fusion. ça a effectivement l'air de marcher mais je souhaiterais
> en savoir plus quant aux mises à jour de structure de base de
> données.
> 1/ Que peut gérer exactement la réplication: ajout/suppression de
> champs, ajout/suppression de tables ,...
> 2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
> table, comment faire ? faut il supprimer la publication en cours, faire
> les modifs, recréer la publication ?? Refaire une capture instantan ée
> ?
> 3/ Apparemment lorsque je fais une capture instantannée, la bas de
> données abonnée devient l'image exacte de la base de données serv eur
> mais perd les modifications sur la base de l'abonné qui n'avaient pas
> été synchronisées? Est ce bien le rôle d'une capture ?
> 4/ En règle général, le retour de l'utilisation de la réplicati on
> par fusion est il bon ?
> 5/ l'activeX gérant la réplication est il intéressant ?
> Merci par avance
>
>
Donc si j'ai un poste client avec des informations non syncrhonisées
et qu'en parallèle je dois mettre en place une nouvelle version avec
des modifications de base importantes, je dois faire comme actuellement
et lancer ces modifications sur le serveur et le poste client. Jusque
là ça ne me dérange pas. Le problème, est cette capture
instantantannée. Si je comprends bien je fais mes modifs sur le
serveur et ensuite une capture est obligatoire. PAr contre je peux lui
indiquer de ne pas écraser les données de mes abonnés. Mais s'il y
avait des modifs en cours sur la base d'un abonné, comment faire pour
qu'elles arrivent sur le serveur ?
Arnaud CLERET a écrit :
> Bonjour,
>
> En effet, les modifications de structure ne sont pas répliquées de manière
> automatique sans repasser par une capture instantanée.
>
> Pour ce qui est de la capture instantanée, vous pouvez spécifier, dans les
> options de la publication, si les données existantes, tables, procédures ...
> sont écrasées ou conservées. Par contre, si vous ne souhaitez pas écraser les
> données existantes, celles-ci ne seront pas pour autant répliquées vers le
> serveur central.
>
> De manière générale, la réplication par fusion est une très bonne chose tant
> qu'elle est utilisée de manière pertinente. De plus, il n'est pas aisée de
> mettre en place ce type de réplication avec la gestion des conflits de
> synchronisation des données.
>
> Pour la notion d'ActiveX permettant le traitement des données lors de la
> réplication, il est fortement conseillé de les utiliser qu'en cas où il ne
> serait pas possible de le faire au travers des procédures stockées de la
> réplication. En effet, les ActiveX ont des impacts énormes sur les
> performances de votre réplication.
> Pour infos, il est tout à fait possible de fournir ces propres procédures
> stockées de réplication plutôt que celle générée lors de la création de la
> réplication. Il suffit pour cela de spécifier leur nom au niveau des options
> de la publication.
>
> --
> arno - http://www.dotnetguru2.org/acleret/
>
>
> "SCJ" a écrit :
>
> > Bonjour à tous,
> >
> > J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
> > Pour synchroniser tout cela, je suis en train de tester la réplication
> > par fusion. ça a effectivement l'air de marcher mais je souhaiterais
> > en savoir plus quant aux mises à jour de structure de base de
> > données.
> > 1/ Que peut gérer exactement la réplication: ajout/suppression de
> > champs, ajout/suppression de tables ,...
> > 2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
> > table, comment faire ? faut il supprimer la publication en cours, faire
> > les modifs, recréer la publication ?? Refaire une capture instantanée
> > ?
> > 3/ Apparemment lorsque je fais une capture instantannée, la bas de
> > données abonnée devient l'image exacte de la base de données serveur
> > mais perd les modifications sur la base de l'abonné qui n'avaient pas
> > été synchronisées? Est ce bien le rôle d'une capture ?
> > 4/ En règle général, le retour de l'utilisation de la réplication
> > par fusion est il bon ?
> > 5/ l'activeX gérant la réplication est il intéressant ?
> > Merci par avance
> >
> >
Donc si j'ai un poste client avec des informations non syncrhonisées
et qu'en parallèle je dois mettre en place une nouvelle version avec
des modifications de base importantes, je dois faire comme actuellement
et lancer ces modifications sur le serveur et le poste client. Jusque
là ça ne me dérange pas. Le problème, est cette capture
instantantannée. Si je comprends bien je fais mes modifs sur le
serveur et ensuite une capture est obligatoire. PAr contre je peux lui
indiquer de ne pas écraser les données de mes abonnés. Mais s'il y
avait des modifs en cours sur la base d'un abonné, comment faire pour
qu'elles arrivent sur le serveur ?
Arnaud CLERET a écrit :
> Bonjour,
>
> En effet, les modifications de structure ne sont pas répliquées de manière
> automatique sans repasser par une capture instantanée.
>
> Pour ce qui est de la capture instantanée, vous pouvez spécifier, dans les
> options de la publication, si les données existantes, tables, procédures ...
> sont écrasées ou conservées. Par contre, si vous ne souhaitez pas écraser les
> données existantes, celles-ci ne seront pas pour autant répliquées vers le
> serveur central.
>
> De manière générale, la réplication par fusion est une très bonne chose tant
> qu'elle est utilisée de manière pertinente. De plus, il n'est pas aisée de
> mettre en place ce type de réplication avec la gestion des conflits de
> synchronisation des données.
>
> Pour la notion d'ActiveX permettant le traitement des données lors de la
> réplication, il est fortement conseillé de les utiliser qu'en cas où il ne
> serait pas possible de le faire au travers des procédures stockées de la
> réplication. En effet, les ActiveX ont des impacts énormes sur les
> performances de votre réplication.
> Pour infos, il est tout à fait possible de fournir ces propres procédures
> stockées de réplication plutôt que celle générée lors de la création de la
> réplication. Il suffit pour cela de spécifier leur nom au niveau des options
> de la publication.
>
> --
> arno - http://www.dotnetguru2.org/acleret/
>
>
> "SCJ" a écrit :
>
> > Bonjour à tous,
> >
> > J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
> > Pour synchroniser tout cela, je suis en train de tester la réplication
> > par fusion. ça a effectivement l'air de marcher mais je souhaiterais
> > en savoir plus quant aux mises à jour de structure de base de
> > données.
> > 1/ Que peut gérer exactement la réplication: ajout/suppression de
> > champs, ajout/suppression de tables ,...
> > 2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
> > table, comment faire ? faut il supprimer la publication en cours, faire
> > les modifs, recréer la publication ?? Refaire une capture instantanée
> > ?
> > 3/ Apparemment lorsque je fais une capture instantannée, la bas de
> > données abonnée devient l'image exacte de la base de données serveur
> > mais perd les modifications sur la base de l'abonné qui n'avaient pas
> > été synchronisées? Est ce bien le rôle d'une capture ?
> > 4/ En règle général, le retour de l'utilisation de la réplication
> > par fusion est il bon ?
> > 5/ l'activeX gérant la réplication est il intéressant ?
> > Merci par avance
> >
> >
Donc si j'ai un poste client avec des informations non syncrhonisées
et qu'en parallèle je dois mettre en place une nouvelle version avec
des modifications de base importantes, je dois faire comme actuellement
et lancer ces modifications sur le serveur et le poste client. Jusque
là ça ne me dérange pas. Le problème, est cette capture
instantantannée. Si je comprends bien je fais mes modifs sur le
serveur et ensuite une capture est obligatoire. PAr contre je peux lui
indiquer de ne pas écraser les données de mes abonnés. Mais s'il y
avait des modifs en cours sur la base d'un abonné, comment faire pour
qu'elles arrivent sur le serveur ?
Arnaud CLERET a écrit :
> Bonjour,
>
> En effet, les modifications de structure ne sont pas répliquées de manière
> automatique sans repasser par une capture instantanée.
>
> Pour ce qui est de la capture instantanée, vous pouvez spécifier, dans les
> options de la publication, si les données existantes, tables, procédures ...
> sont écrasées ou conservées. Par contre, si vous ne souhaitez pas écraser les
> données existantes, celles-ci ne seront pas pour autant répliquées vers le
> serveur central.
>
> De manière générale, la réplication par fusion est une très bonne chose tant
> qu'elle est utilisée de manière pertinente. De plus, il n'est pas aisée de
> mettre en place ce type de réplication avec la gestion des conflits de
> synchronisation des données.
>
> Pour la notion d'ActiveX permettant le traitement des données lors de la
> réplication, il est fortement conseillé de les utiliser qu'en cas où il ne
> serait pas possible de le faire au travers des procédures stockées de la
> réplication. En effet, les ActiveX ont des impacts énormes sur les
> performances de votre réplication.
> Pour infos, il est tout à fait possible de fournir ces propres procédures
> stockées de réplication plutôt que celle générée lors de la création de la
> réplication. Il suffit pour cela de spécifier leur nom au niveau des options
> de la publication.
>
> --
> arno - http://www.dotnetguru2.org/acleret/
>
>
> "SCJ" a écrit :
>
> > Bonjour à tous,
> >
> > J'ai un serveur sous SQL server 2000, des portables sous MSDE 2000.
> > Pour synchroniser tout cela, je suis en train de tester la réplication
> > par fusion. ça a effectivement l'air de marcher mais je souhaiterais
> > en savoir plus quant aux mises à jour de structure de base de
> > données.
> > 1/ Que peut gérer exactement la réplication: ajout/suppression de
> > champs, ajout/suppression de tables ,...
> > 2/ si la réplication ne sait pas distribuer l'ajout d'une nouvelle
> > table, comment faire ? faut il supprimer la publication en cours, faire
> > les modifs, recréer la publication ?? Refaire une capture instantanée
> > ?
> > 3/ Apparemment lorsque je fais une capture instantannée, la bas de
> > données abonnée devient l'image exacte de la base de données serveur
> > mais perd les modifications sur la base de l'abonné qui n'avaient pas
> > été synchronisées? Est ce bien le rôle d'une capture ?
> > 4/ En règle général, le retour de l'utilisation de la réplication
> > par fusion est il bon ?
> > 5/ l'activeX gérant la réplication est il intéressant ?
> > Merci par avance
> >
> >
