Distributed transaction replication?

Tja, der er jo muligheden for at bruge transactional replication. Denne form for replikering garanterer (i vid udstrækning), at de ændringer, der er foretaget på publisher også vil blive foretaget på subscriber. Imidlertid vil der altid være et eller andet delay, som for det meste dog vil være minimalt.

Hvis denne form for delay er uhensigtsmæssig, skal man over i et eller andet med at bruge two-phase commit, hvilket er væsentligt mere besværligt. Det vil jeg ikke uddybe mere, med mindre du ønsker det...!

Ja jeg kender godt transactional replication, som i øvrigt allerede bruger two-phase commit, det er ikke det der er problemet. I MS SQL server 6.5 og 7.0 finder man noget der hedder distributed transaction, hvilket kun replikerer i de subscribers der er knyttet til publisheren, hvis der er forbindelse til ALLE subscribers, ellers laves der roll-back på de andre. Jeg ved at det kan lade sig gøre i MS SQL 2000, men hvordan?

Øhm, jeg tror du bytter lidt rundt på nogle ting her. Transactional replication bruger netop ikke two-phase commit. Two-phase commit kræver, at der er 100% forbindelse mellem de involverede servere, det gør transactional replication ikke!

Distributed transactions, som jeg tænker på dem (prøv selv at slå det op i books online), bruger netop two-phase commit til at sikre, at alle involverede servere committer det samme. Men det ikke som sådan noget med replikering at gøre. I replikerings-sammenhæng er transactional replication det nærmeste man kommer dette.

Kom til at tænke på: Måske tænker du på Immediate Updating Subscribers?

Her replikerer man på vanlig vis med f.eks. Transactional Replication fra Publisher til Subscriber, men det er muligt at opdatere data direkte på Subscriber, som så \"replikeres\" til Publisher ved hjælp af two-phase commit.

Og det hed vist nok noget andet på SQL 6.5 og 7. Men på 2000 hedder det Immediate Updating Subscribers. Slå op under \"immediate updating\" i Books Online.

Du har ret, det jeg kiggede på var transactional med updateable subscribers. Jeg har så fundet ud af at det bare er almindelig transactional jeg skal bruge, dvs. en skeduleret opdatering. Da jeg kun skal opdatere een gang i døgnet, ka jeg vel lige så godt bare sætte en tid på en transactional mest for at mindske størrelsen af de data der skal sendes, eller er det bedre at bruge merge?

Hvilken retning tænker du på her? Fra Publisher til Subscriber eller den anden vej??

Hvis det er fra Publisher til Subscriber skal du bare lave en transactional som er skeduleret.

Fra Subscriber til Publisher skal du bruge merge. Immediate updating opdaterer jo med det samme, så det skal du ikke bruge, hvis det kun er en gang i døgnet (der er faktisk noget med at man kan lave en kø i forbindelse med dette, men så begynder det vist at blive langhåret).

Men du skal selvfølgelig lige overveje hvor lang tid Publisher og Subscriber må være \"out of sync\" før du vælger metode og skedulering.

-

Kan ikke give points torbenkoch, ved ikke hva der sker!!