[ Pobierz całość w formacie PDF ]
.Jeden zużytkowników straci swoje zmiany, a jego rekord przesłany zostanie do tabeli konfliktów.u Błąd powtórzenia klucza.W czasie synchronizacji dwa rekordy mają taką samą wartość w polu klucza.u Naruszenie poprawności wartości w tabeli.W czasie synchronizacji rekord narusza zasady poprawności danychzapisane podczas tworzenia projektu tabeli (puste ciągi znaków, wartości poza zakresem itp.).Gdy wystąpi naru-szenie reguł poprawności, rekord jest odrzucany.u Naruszenie więzów integralności.Gdy usunięty zostanie rekord w replice, który jest jedną ze stron relacji jedendo wielu, wszystkie rekordy bazujące na kluczu obcym zostaną w trakcie synchronizacji odrzucone.Gdyzmieniamy klucz główny rekordu w replice, zmiana klucza spowoduje, że rekordy bazujące na poprzedniejwartości klucza w innych replikach zostaną odrzucone.Rekordy repliki z kluczem obcym bazującym nanieprawidłowej wartości klucza głównego również zostaną odrzucone.W każdym z tych przypadków kreator rozwiązywania konfliktów pokaże użytkownikowi odrzucony rekord.Użytkownikmoże zdecydować, czy powtórnie wykonać zmiany, anulować zmiany lub zmienić dane powodujące konflikt.Access używa wbudowanej procedury rozwiązywania konfliktów.Kreator rozwiązywania konfliktów pokazujeużytkownikowi każdy konflikt i musi on zadecydować, który rekord zawiera prawidłowe dane.Aby uniknąć tego procesu, można użyć właściwości ConflictFunction.Pozwala ona na użycie własnej proceduryrozwiązywania konfliktów, które wystąpiły w czasie synchronizacji lub może wskazać replikę, której rekordy są zawszenajważniejsze w wypadku wystąpienia konfliktu.Jako wartość właściwości ConflictFunction należy przypisać nazwęfunkcji, która ma być wywołana w wypadku konfliktu.Musi być to nazwa funkcji, nie można podać nazwy procedury.Jeżeli właściwość ta nie jest ustawiona, Access wywoła wbudowaną funkcję rozwiązywania konfliktów.Funkcja rozwiązywania konfliktów jest wywoływana po zakończeniu synchronizacji.Gdy tworzymy funkcjęrozwiązywania konfliktów, operujemy na zawartości tablicy konfliktów w Twojej replice, aby ocenić konflikt oraz zmienićrekord lub zbiór rekordów przy użyciu zwykłych mechanizmów manipulacji danymi (DAO, ADO, RDO lub SQL).Gdy wprowadzasz własną procedurę rozwiązywania konfliktów, zastępujesz nią wbudowany algorytm rozwiązywaniakonfliktów.Powinieneś dokładnie rozważyć sytuacje, w których jest to potrzebne.Jedną z możliwych sytuacji, kiedymożesz skorzystać z napisania własnej funkcji rozwiązywania konfliktów jest to gdy chcesz sprawdzić przynależnośćużytkownika do grupy, aby zdecydować, czy jego zmiany mają pierwszeństwo przed zmianami innego użytkownika.Podejście takie pozwala na pracę użytkownika na różnych replikach bez względu na priorytet danej repliki w topologiireplikacji.Domyślnie Jet 4.0 rozwiązuje konflikty przy użyciu dwóch algorytmów bazujących na priorytetach oraz unika konfliktówprzez ich poszukiwanie tylko na poziomie kolumn.W Jet 4.0 każdej replice jest przypisana wartość priorytetu.Ta liczba wyznacza miejsce repliki w topologii.Jeżeli dwierepliki spowodowały konflikt, Jet rozwiązuje go, bazując na ich relacjach w topologii.Zmiany repliki o wyższympriorytecie są ważniejsze.W wypadku remisu ważniejsza jest replika z mniejszą wartością ReplicaID (replika utworzonawcześniej).Algorytm ten jest zbliżony do używanego w SQL Server 7.Wartość priorytetu przyjmuje wartości od 0 do 100.W trakcie tworzenia repliki otrzymuje priorytet równy 90% wartościzródła.W Jet 4.0 konflikty powinny wystąpić rzadziej niż we wcześniejszych wersjach.We wcześniejszych wersjach występowałkonflikt, gdy dwóch użytkowników zmienia to ten sam rekord, nawet, gdy zmienili dane w różnych polach.W Jet 4.0dwóch użytkowników może zmienić różne pola tego samego rekordu i konflikt nie nastąpi.Zledzenie zmian na poziomiekolumn radykalnie redukuje częstość konfliktów i odciąża użytkowników od rozwiązywania tych konfliktów.Zledzenie zmian na poziomie kolumn jest domyślnie włączone w Jet 4.Jeżeli Twoja aplikacja potrzebuje śledzenia zmianna poziomie rekordów, opcja musi być zmieniona przed przystosowaniem tabel do replikacji.Aby wybrać pomiędzyśledzeniem zmian na poziomie kolumn i rekordów, użyj parametru columntracking metody replica.Ma- 415Rozdział 22.f& Replikacja i JROkeReplicable.Ustawienie tego argumentu na True włącza śledzenie zmian na poziomie kolumn, a False włączaśledzenie zmian na poziomie rekordów.Poniższa metoda powinna przystosować bazę do replikacji ze śledzeniem zmian napoziomie rekordów:Replica.MakeReplicable CurrentProject.Connection, FalseWłaściwość ConflictTablesWłaściwość ta wskazuje na obiekt RecordSet zawierający listę tabel i skojarzonych z nimi tabel konfliktów.Wywołanie właściwości ConflictTables zwraca RecordSet zawierający dwie kolumny: TableName i związaną z niąConflictTableName.Dla każdej tabeli z konfliktami istnieje tabela przechowująca rekordy powodujące konflikty.Właściwość ConflictTables można tylko odczytywać.Otwierając tabelę o nazwie podanej w polu ConflictTableName właściwości ConflictTables, można obejrzeć rekordstracony przy synchronizacji oraz obejrzeć jego pola specyficzne dla replikacji.Na wydruku 22.1 pokazany jest przykład prostej funkcji rozwiązywania konfliktów.Używa on ADO, ADOX i JRO doprzetworzenia wszystkich konfliktów przy użyciu właściwości ConflictTables.Wydruk 22.1.Proste rozwiązywanie konfliktówFunction CustomDataConflictResolver()Dim jro As New jro.ReplicaDim cat As New ADOX.CatalogDim conflrs As New RecordsetDim rs As New RecordsetOn Error Goto CustomDataConflictResolver ErrorSet jro.ActiveConnection = CurrentProject.ConnectionSet cat.ActiveConnection = CurrentProject.Connection' jro.ConflictTables zwraca Recordset z nazwami tabelami' zawierających konfliktySet conflrs = jro.ConflictTables' Dla każdej związanej tablicy konfliktów rozpoznaj konflikt' i rozwiąż goWhile Not conflrs.EOF' Otwórz tabelę aktualnego konfliktu i analizuj utracony rekordrs.Open "Select * From " & conflrs.Fields(1), jro [ Pobierz całość w formacie PDF ]
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • agnieszka90.opx.pl