Je prends un peu le truc en cours de route mais les bases sont sur 2 instances distinctes ou pas ?Citation:
j'ai deux serveurs SQL hébergeant des bases de données différentes (A et B).
Version imprimable
Je prends un peu le truc en cours de route mais les bases sont sur 2 instances distinctes ou pas ?Citation:
j'ai deux serveurs SQL hébergeant des bases de données différentes (A et B).
Oui, vous faites une erreur : la réplication n'a pas besoin de bases identiques et heureusement, car cela signifierais que l'on réplique tout et dans ce cas ce n'est plus de la réplication, mais la duplication d'une base !Citation:
Envoyé par MuadDib_CH
A +
1. Je n'ai pas la maîtrise du code des applications qui tournent sur les bases A et B (2 applis différentes)[/QUOTE]Citation:
Envoyé par MuadDib_CH
OK, normal...
Pas OK, pas normal et contredisant votre cahier des charges. Si vous ne pouvez pas modifier la base alors AUCUNE solution n'est possible et bien entendu pas celle du trigger, puisqu'il y a ajout d'un objet à la base.Citation:
2. Je ne peux pas modifier la structure de la base de données A
Cette posture est stupide à imbécile ! En effet, selon les règles de Codd et en particulier la n°9 :
"Les applications et les programmes terminaux sont logiquement inaffectés, quand des changements de tous ordres, préservant les informations et qui ne leur portent théoriquement aucune atteinte, sont apportés aux tables de base (restructuration)."
Il n'y a donc aucun danger à modifier la structure d'une base en respectant la réserve donnée sauf si le logiciel a été particulièrement mal conçu !
A lire : http://sqlpro.developpez.com/SGBDR/R...egles_codd.pdf
Deux méthodes en dehors du trigger (qui est trop synchrone) sont envisageables :Citation:
3. Mon but est de faire l'intégration de deux logiciels:
a. Le logiciel B est spécialisé dans un domaine que A ne fait que survoler
b. Le logiciel A a besoin d'une partie des données de B pour continuer $ fonctionner correctement malgré qu'il soit moins spécialisé.
Voilà...
1) la réplication avec un temps de latence "dès que possible"
2) l'utilisation de service broker.
ces deux solutions donnant un effet "au fil de l'eau" en matière de perception des données, vu du côté utilisateur. En pratique, c'est de l'ordre de la seconde.
Dans votre cas, c'est plutôt vers Service Broker que je m'orienterais vu que vous n'avez que peu de flux. Et c'est la solution la plus robuste et la moins couteuses en terme de ressources.
A +