Polski Związek Krótkofalowców |
|
Polski Klub Radiovideografii |
|
Nawigacja: Projekt AWARD_SECRETARY i jego przeznaczenie > Wczytywanie danych ze zbioru ADIF |
|
| Rozszerz wszystkie elementy Zwiń wszystkie elementy |
Po uruchomieniu zainstalowanego AWARD_SECRETARY z ikony na pulpicie
lub z menu windowsów START - PROGRAMY - AWARD_SECRETARY
-------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------
zglasza się program AWARD_SECRETARY ,
 |
| RozbIezności miedzy Lista DXCCARRL- a lista DXC V z CUBLOG jesli istnieją |
a następnie ikona wczytywania danych wstepnych
 |
| Ekran 2-gi przy starcie. Następuje utworzenie lub aktualizacja tablic wstepnych programu potrzebnych póżniej do obliczenia dyplomu |
 |
| Ekran Wykonano przy starcie |
Należałoby teraz wczytac dane o QSO z jakiegoś loggera . Dokonuje się tego przez naciśnięcie Import ze zbioru ADIF w menu głównym
 |
| Import zbioru danych ze zbioru ADIF |
Pojawi sie nam okno w którym wszystko jest wyjasnione , czy mamy polegać tylko na danych z loggera , czy tez dane te
------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
 |
| Okno wyboru czy dane pobieramy tylko z Logger czy tez dane z Logger sprawdzamy na stronie www CLUBLOG |
Ja ze swe strony usilnie zalecam przepuszczenie danych przez CLUBLOG . O potrzebie stosowania CLUBLOG pisżę tutaj oraz tutaj oraz tutaj Podam tylko iż ja na 22 tys QSOs dla pliku ADIF z Logger32 otrzymałem :tj
| • | 4 QSOs miało iinny numer ADIF Number ( w Logger32 jest ono nazywane DXCC)., W zasadzie były to znaki nie zaliczane do dyplomów DXCC tj DXCC = 0 , CQZone = 0 , ITUZone = 0 .. |
| • | 270 QSOs miało inny numer CQZone |
| • | 277 QSOs mialo inny CQZone lub ITUZone |
Tak mała ilość różnic w ADIF Numer wynikała z tego iz w Logger32 istnieje mozliwość sychroniazacji ADIF Number z CLUBLOG. Natomiast dla CQZone i IITUZone Logger32 ma własne procedury do okreslenia tych danych
Po wybraniu OK dalszy przebieg programy wygląda jak niżej
 |
| Wybranie zbioru ADIF z danymi z Logger-a |
Teraz pojawi sie ekran
 |
| Okna błędow i komunikatów w czasie wczytywania danych z Logger-a |
Teraz mamy do dyspozycji dwa przyciski ;
wprowadz/aktualizuj bazę QSOs oraz
Usuń wszystkie istniejące QSOs i dyplomy -wprowadz nowe dane z
 |
| Buttony do wprowadzania lub aktualizacja danych o QSOs W naszym przypadku był wybrany button Wprowadz.aktualizuj bazę QSOs |
W tym miejscu należy się czytelnikowi wyjasnić na czym polega
Synchronizacja danych w bazie danych AWARD_SECRETARY z danymi pochodzącymi z Logger-a
Konkretnie chodzi o synchronizacje tablicy MYSQL QSOS_AWARS z danymi z Loggera .
W maju 2016 uzyskałem 4 dyplomy ARRL - u metodą połączenia dyplomów opisaną tutaj .
W roku 2022 chciałem uzyskać uzupelnienia - endorsement dla uzyskanych dyplomów. Wczytałem nowe dane z Logger32 i jakie było moje zdziwienie , gdy około 120 QSOs miało zwiekszony TIME_ON o 1 sec w stosunku do mojego poprzedniego stanu . No coz pomyslałem - dokonam korekty TIME_ON w logger32 . Ale niestety Logger32 nie pozwalał na to , twierdząc iz tworzy to duplikat Nie mogłem pozwolić na stworzenie dupikatu w mojej tablicy QSOS_AWARDS Być może że pierwsze QSO zostało już użyte do jakiegoś dyplomu i osiągnelo stan AWARDED Zużyłem mnóstwo pracy by rozwiązać ten problem - a konkretnie tej jednej parszywej sekundy . Zauważyłem iż dla tych 120 QSOs zazwyczaj TIME_ON było większe o 1 sec od TIME_OFF. Ewidentny błąd logiczny. Ten błąd zauważyli autorzy CLUBLOG ,gdyz w niektórych przypadkach jako TIME_ON wstawiali wartość równą TIME_OFF . Więc ja dałem w odpowiednie miejsce w programie warunek::
Jesli TIME_ON jest większy od TIME_OFF to wtedy zastosuj warunek TIME_ON = TIME_OFF .
Zmniejszyło to ilość różnic do 3 iak poniżej
Sprawdzam synchronizację QSOs miedzy loggerem a tablicą MYSQL QSO_AWARDS
--------------------------------------------------------------
FROM LOGGER
ID_QSO CALL QSO_DATE TIME_ON TIME_OFF BAND MODE
1206 9J2TJ 1978-07-21 18:25:01 18:30:00 20M SSB
FROM TABLE QSO_AWARDS
1205 9J2TJ 1978-07-21 18:25:00 18:30:00 20M SSB
Istnieje QSO lecz ma rózne TIME_ON/TIME_OFF lub DATE_QSO - robię poprawke w MYSQL QSOS_AWARDS
No Of Duplicates = 1
--------------------------------------------------------------
FROM LOGGER
ID_QSO CALL QSO_DATE TIME_ON TIME_OFF BAND MODE
1401 DL6NB 1979-04-22 14:37:00 14:37:00 40M SSB
FROM TABLE QSO_AWARDS
277 DL6NB 1979-04-22 14:37:00 14:37:00 40M SSB
Istnieje QSO lecz ma rózne TIME_ON/TIME_OFF lub DATE_QSO - robię poprawke w MYSQL QSOS_AWARDS
No Of Duplicates = 2
--------------------------------------------------------------
FROM LOGGER
ID_QSO CALL QSO_DATE TIME_ON TIME_OFF BAND MODE
21343 T88TW 2011-09-16 18:18:05 18:18:44 20M SSB
FROM TABLE QSO_AWARDS
21345 T88TW 2011-09-16 18:18:05 18:18:44 20M SSB
Istnieje QSO lecz ma rózne TIME_ON/TIME_OFF lub DATE_QSO - robię poprawke w MYSQL QSOS_AWARDS
No Of Duplicates = 3
==========================================
Wyniki sprawdzenia synchronizacji zostały zapisane w zbiorze = Error_report_synchronize.txt
W czasie sprawdzania synchronizacji w tablicy QSOS_AWARDS zostają dokonane odpowiednie korekty , zabezpieczające przed powstaniem duplikatu .
No więc poszukajmy jakie dane były w tablicy QSOS_AWARDS przed dokonaniem synchronizacji
 |
| Dla stacji 9J2TJ istnieje 1 dzien rożnicy - zle wypełniona karta QSL |
 |
| Dla stacji DL6NB istnieje 9 lat rożnicy - zle wypełniona karta QSL |
 |
| Dla stacji T88TW QSO ma róznice w pasmie BAND - dla CRC jest to 10 M podczas gdy w rzeczywistości zostało przeprowadzone na 20 M |
Dlaczego w bazach danych jest tak wazne by nie dopuścić do powstania duplikatów
Każda tablica w MYSQL zazwyczaj posiada tzw index przypisany konkretnemy polu . W przypadku Loggerów istnieje co prawda pole zwane numerem QSL , ale nie może byc ono stosowane , gdyż np Logger32 dopuszcza przenumerowanie QSOs . Potrzebne jest jakieś pole ,które jednoznacznie identyfikuje QSO . W tym celu utworzyłem pole nazwane
CRC , które jest sumą stringową pól DATE_QSO + TIME_ON + CALL + BAND + MODE
Np wpis
1966-04-0305:27:00UW9WF20MCW
oznacza iz jest to QSO przeprowadzone z data 1966-04-03 o czasie 05:27:00 ze stacją UW9WF na pasmie 20M emisją CW. Jest to pole indeksowane w MYSQL , co znacznie przyśpiesza proces poszukiwania QSO . Powstanie duplikatu oznacza iż być mozej już 1-sze QSO zostało użyte w jakimś dyplomie lub co gorsze uzyskało juz status AWARDED .
Po dokonaniu synchronizacji jesli istnieją jakieś różnice pojawi sie komunikat
 |
| Komunikat o błędach w synchronizacji jesli jakieś istnieją. Zalecam wybranie teraz CANCEL tj zakonczenie programu , ponowne uruchomienie i ponowne wczytanie danychTeraz już nie powinny byc meldowane te różnice gdyż poprawki zostały już dokonane w odpowiedniej tablicy MYSQL |
 |
| Brak błędow w synchronizacji po wyjściu CANCEL w poprzednim ekranie i ponownym uruchomieniu programi i wczytaniu danych |
Teraz wybieramy button Wprowadż/akuaizuj bazę QSOs
 |
| Zapis danych w formacie CSV |
Czas wprowadzania danych tj zapis w formacie CSV dla około 23 tys QSOs na maszynie Windows 10 wynosi około 35 sec .
Teraz nastepuje tworzenie zbioru pomocniczego
 |
| Tworzenie zbioru pomocniczego |
 |
| Wykonano - komunikat końcowy |
Teraz zobaczmy wyniki w innym ułozeniu .
 |
| Efekt końcowy po kliknięciu na buttonie Pokaztylko selekconowane pola |
Jeśli wybrałeś w ikonie NO - tj wspólpracę z CLUBLOG to powinenies przejść teraz do punktu
|
Nawigacja: Projekt AWARD_SECRETARY i jego przeznaczenie > Wczytywanie danych ze zbioru ADIF |
|
| Rozszerz wszystkie elementy Zwiń wszystkie elementy |