Vi har en merge replikering af en tabel. Denne tabel har naturligvis en unique-identifier, men derudover har den af historiske grunde (samt af hensyn til andre applikationer, som benytter den samme tabel) en tæller, som kører med indendity increment. Denne tæller giver problemer, når man både kan oprette nye poster på publisher og subscriber.
Er der en måde, så man kan undgå den konflikt ??
Tællerens værdi har ikke den store betydning på subscriberen, så det, vi gerne vil, er, at tælleren godt kan blive tildelt en temporær værdi på subscriberen, men ved replikering skal den så tildeles den \'korrekte\' værdi i forhold til publisherens identity increment.
Not really sure I understand your problem, but an identity gets incremented by the increment value automatically when creating the record. Because you can create records two diffrent places then the same id will more than likely exist. You could set the seed value to something very high for one of the tables, or use a GUID instead of an identity. You could also remove the identity on one of the tables.
another idea! On one server set the seed (start value) to 1 and the other to 2. Then set the increment to 2. This will have the effect of one server have odd ID\'s and the other even!
I like the idea of the increment of two! The only problem is that it is very likely that a lot of records already exist, which will make it necessary to have the seed on the subscriber set to a rather large number.
I had this problem somewhere else, where the solution was to eliminate the identity field and reprogram the necessary applications. Rather expensive...
Well, you probably could - unless you have foreign keys pointing to the tables, which of course would make that a lot harder. This was also done in my above mentioned problem.
The \"right\" and clean way to do this is to reprogram all the applications to use the uniqueidentifier, but it sure is hard work - and expensive.
Nu kender jeg lidt til den aktuelle problemstilling, som, så vidt vides, ikke er løst endnu (det er jo ferietid).
Vi har en central sql-server med en database, som benyttes af en række eksisterende applikationer. Det nye består i, at vi har nogle bærbare, som hver har en lokal database, hvor der sker en replikering med den centrale database. Det vil sige, at vi har flere subscribers. (derfor kan ideen med lige og ulige tællere desværre ikke rigtigt benyttes)
På disse bærbare kører en nyudviklet applikation, som er uafhængig af fortløbende tællere. Applikationen skal benyttes, når man er væk fra kontoret, således at man har data tilgængelig, uden at skulle have forbindelse til serveren.
Problemet er, at de eksisterende applikationer, som kører op mod den centrale database, er baseret på fortløbende tællere og brugen af disse til fremmednøgler.
Det er en stor opgave, at skulle til at redesigne de eksisterende applikationer, så de er uafhængige af disse tællere. På den anden siden er det nødvendigt, at det er muligt at lave alle operationer på de bærbare (incl. oprettelse af poster). Dette resulterer desværre i den omtalte konflikt grundet de fortløbende tællere, som bliver talt op på både server og bærbar, når der sker nyoprettelser begge steder.
Hvis der kun kører den nyudviklede applikation på den bærbare, dvs. der er ingen applikationer på den bærbare, der er afhængig af den løbende tæller (identity), må det være muligt at sætte replikeringen op, så identity feltet ikke kommer til den bærbare. Derved slipper man for, at der bliver oprettet nye identity værdier på den bærbare, men at de kun bliver genereret, når man replikerer fra den bærbare til hovedserveren.
Ja, verdenen ville være simplere med enkeltbrugersystemer :)
Nu følger jeg kun projektet lidt på sidelinjen, så jeg kender ikke de aktuelle mulighederne for opsætning af replikeringen, men det lyder jo besnærende. Vores mand på sagen er desværre på ferie lige nu.
Its not easy to make suggestions when we dont know anything about the design of the database or the applications in use! What puzzles me though is that when a record is created on the publisher (central dB), the ID is important for the applications using the central dB. But with records created on the subscriber (laptops) the ID isnt important. Why replicate, isnt the data created by the subscribers, not used by the applications using the central dB? If they do use these records, then they too must have need for this ID. I have a feeling that you should maybe look at DTS instead of replication!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
