[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem CRC
A JEDNAK SIĘ UDAŁO
Podaję przepis jak sobie radzić z CRC w takich przypadkach (przynajmniej
jeśli chodzi o progressa 7.3).
Na początek przeprowadziłem testy, które doprowadziły mnie do następujących
wniosków:
1. Po założeniu nowej tabeli nowozałożone pola mają _Field-rPos numerowane
od 2
2. Kolejne _Field-rPos dodawanych pól są autoinkrementowane o wartość 1
bez względu na typ pola
3. Wartość pola ORDER nie wpływa na kolejność przypisywania r-Pos podczas
wczytywania df-ki
4. Kolejność przydzielania rPos podczas wczytywania df-ki zależy tylko i
wyłącznie od
kolejności występowania poszczególnych pól w df-ce, poza tym rPos są
generowane od początku
jeśli mamy usuniętą tabelę i wczytujemy na nowo jej definicję
5. Typ poszczególnych pól w tabeli ma znaczenie przy crc, czyli 5 pól char
daje inne crc niż 5 pól integer
6. Kolejność pól tych samych typów w df-ce również ma wpływ na crc
7. Zmiana wartości pola order w polach tego samego typu również ma
znaczenie przy crc
8. Wartośc rPos pola wpływa na crc, czyli tabela Test i pole Pole1 z
rPos=2 ma inne crc niż tabela Test i pole Pole1 z rPos=3
9. Typ pola usuniętego z tabeli nia ma znaczenia! Czyli jeśli mamy tabelę
Test i pole Pole1 z rPos=3,
to nie ma znaczenia czy kiedyś pole na rpos=2 było integer czy char
10. RecId nie wpływa na crc
11. _Idx-num w tabeli _Index nie ma znaczenia przy crc
12. Kolejność dodawania indeksów do tabeli nie ma znaczenia dla crc
WNIOSKI
Jeśli mamy 2 bazy i do pustej wzorcowej bazy danych wciągnęliśmy df-kę z
bazy głównej,
i jeśli występują różnice w crc to jedyną przyczyną tego zjawiska jest
_Field-rPos !!!
Dlatego że ilość pól i indeksów a także sekwencje, wszystkie nazwy są takie
same siłą rzeczy.
Jak sobie z tym poradzić:
1.) Wyłapać tabele które mają niezgodne CRC.
2.) Wydrukować _Field-rPos wszystkich pól tej tabeli
3.) Tak zmodyfikować df-kę, aby po wciągnięciu _Field-rPos były identyczne
w drugiej bazie
4.) Zrobić to metodą jaką zasugerował pan Henryk Jusza, czyli w "dziury" w
pliku df wpisać pola tymczasowe
dowolnego typu, a potem w Data Dictionary usunąć te pola tymczasowe,
dzięki temu ustawianie
_Field-rPos będzie pod naszą kontrolą.
5.) Porównać CRC obu tabel i wszystko gra
P.S.
Z dokumentacji wyczytałem, że na CRC wpływają tylko: _File, _Field, _Index,
_Index-Field, _Sequence.
Tutaj mam do kolegów kolejne pytanie:
Otóż znalazłem tabelę, która w bazie pierwotnej ma złe CRC,
tzn wartość CRC jest nieadekwatna do zawartości tabeli.
Powoduje to jedno pole, gdy wejdziemy w to pole w Data Dictionary
i naciśniemy tylko przycisk Save, CRC się zmienia i ustawia się na
właściwą wartość.
Jaka może być tego przyczyna i jak sobie z tym poradzić, otóż,
"sztuczne modyfikowanie" df-em własności tego pola nic
nie daje - dalej jest błędne crc.
Czy istnieje jakieś polecenie progressowe, które zrobi z danym polem
to samo co przycisk Save w Data Dictionary?
Pozdrawiam, Sławek Łątka.
Henryk Jusza @zeto.bydgoszcz.pl on 2002-04-04 16:36:30
Please respond to progress@zeto.bydgoszcz.pl
Sent by: owner-progress@zeto.bydgoszcz.pl
To: progress@zeto.bydgoszcz.pl
cc:
Subject: Re: Problem CRC
Skoro tak to czy moja teoria jest słuszna:
Jeśli mamy tabelę X, która ma n pól w bazie danych,
i jeśli wygeneruję n df-ek a w każdej z nich będzie df-ka dotycząca tylko
jednego pola,
i jeśli napiszę procedurę która przeanalizuje n! kombinacji df-ek,
a po każdym wczytaniu kombinacji sprawdzę crc z dugą bazą, to jest szansa,
że trafię na taką kombinację dfek, że zniknie mi problem crc w takiej
tabeli?
Jesli dobrze rozumiem, to chce Pan wielokrotnie tworzyć schemat tablicy
układjąc w pliku *.df definicje pól tablicy w różnych kolejnościach aż
trafi się we własciwą. Być może to się uda, tego nie próbowałem.
Myślę że ten proces udałoby się skrócić, bo przecież w jakiej kolejności te
pola są w zapisach to wiadomo, bo ta informacja jest w polach _Field.
_Field-rPos schematu tablicy ale w starej bazie, nie nowej, bo tu ich
wartość jest już zmieniona. Postąpiłbym następująco:
- definicje pól w *.df poukładałbym w kolejności wynikającej z
_Field._Field-rPos w STAREJ bazie, natomiast wszystkie prametry pól
przyjąłbym takie jakie są aktualnie zachowując dotychczasową wartość
ORDER
- jeśli w numeracji _Field._Field-rPos występują przerwy, to te dziury
zapełniłbym definicjami jakichś sztucznych pól
- po utworzeniu schematu tablicy za pomocą takiego *.df pokasowałbym te
sztuczne pola
Jeśli obsługa słownika tworzy pola według kolejności ich występowania w
*.df
a nie według ORDER, to być może sztuczka się uda i wartości _Field.
_Field-rPos uzyskają pierwotną wartość. Sam jestem ciekaw. Byłbym
wdzięczny, gdyby Pan podzielił się wynikami tego eksperymentu.
Pozdrawiam,
Henryk Jusza mailto:henju@pg.gda.pl
-------------------------------------------------
Ośrodek Informatyczny Politechniki Gdańskiej
Pracownia Rozwoju Oprogramowania
tel (058) 347-28-01 fax (058) 347-24-63
------
Strona WWW: http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy: listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------