Reading_data_from_the_ADIF

After running installed AWARD_SECRETARY from the desktop icon

-------------------------------------------------------------------------------------------------------

In the event of a failure of the Internet network, the description of how to check the causes of the failure can be found here

If there is no connection to CLUBLOG.org, the icon below will not appear, ie the program will go to the next icon like here.

-------------------------------------------------------------------------------------------------------

or from the windows menu START - PROGRAMS - AWARD SECRETARY the program AWARD_SECRETARY is reported,

Diffrence betwen official LISTDXCC
from ARRL and from CLUBLOG if exists

and next the preload data loading icon

Second ekran in the start..
Will be created preliminary
tables needed for calculate awards

Screen DONE

Now we should load the QSO data from some logger. This is done by clicking Import from ADIF in the main menu

A window will appear in which everything is explained, whether we should rely only on the data from the logger or the data pass through CLUBLOG

-------------------------------------------------------------------------------------------------------

In the event of a failure of the Internet network, the description of how to check the causes of the failure can be found here

If there is no connection to CLUBLOG.org, the icon below will not appear, ie the program will go to the next icon like here.

Selection window whether we download data
only from the Logger or check the data from
the Logger on the website www CLUBLOG

For my part, I strongly recommend passing the data through CLUBLOG. I write about the need to use CLUBLOG here and here and here .I will only mention that I received 22 thousand QSOs for the ADIF file from Logger32: i.e.accepted for awards

•	4 QSOs had a different ADIF Number (in Logger32 it is called DXCC). In fact, these were callsign not accepted in DXCC awards, i.e. DXCC = 0, CQZone = 0, ITUZone = 0 ..

•	270 QSOs had a different CQZone number

•	277 QSOs had a different CQZone or ITUZone

Such a small number of differences in ADIF Number was due to the fact that in Logger32 have possibiility to synchronize ADIF Number with CLUBLOG. However, for CQZone and IITUZone Logger32 has its own procedures to determine this data

After selecting OK, the further course of the screen looks as follows

Chose file wth data from logger

Now appear screen

Windows with message about errors

Now we have two buttons for chose

enter / update database or

Delete all QSOs and diplomas - enter new data

Buttons for entering or
update data about QSOs
In our case, he was chosen
button Enter update QSOs database

At this point, the reader should be told what it is about

Data synchronization in the AWARD_SECRETARY database with the data from

Specifically, it is about the synchronization of the table MYSQL QSOS_AWARS table with the data from the Logger.

In May 2016 I obtained 4 ARRL diplomas - with the method of combining awards described here.

In 2022 y, I wanted to obtain supplements - endorsement for the obtained awards. I have loaded new data

from Logger32 and what was my surprise when about 120 QSOs had TIME_ON increased by 1 sec

compared to my previous state. Well, I thought about it - I will correct TIME_ON in logger32. But unfortunately Logger32 did not allow this, claiming that it creates a duplicate. I couldn't allow a duplicate to be created in my QSOS_AWARDS table. Perhaps the first QSO had already been used for some award and went AWARDED. I used a lot of work to fix this problem - specifically that one lousy second. I noticed that for these 120 QSOs it is usually TIME_ON was 1 sec greater than TIME_OFF

Obvious logical error. This error was noticed by the authors of CLUBLOG, because in some cases they inserted a value equal to TIME_OFF as TIME_ON. So I put the condition in the right place in the program:

If TIME_ON is greater than TIME_OFF then use the condition TIME_ON = TIME_OFF.

This reduced the number of differences to 3 as below

I check the synchronization of QSOs between the logger and the MYSQL QSO_AWARDS table

--------------------------------------------------------------

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

There is a QSO but it has different TIME_ON / TIME_OFF or DATE_QSO - I am making a fix in 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

There is a QSO but it has different TIME_ON / TIME_OFF or DATE_QSO - I am making a fix in 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

There is a QSO but it has different TIME_ON / TIME_OFF or DATE_QSO - I am making a fix in MYSQL QSOS_AWARDS

No Of Duplicates = 3

==========================================

Synchronization check results sync files have been saved in the file = Error_report_synchronize.txt

During the synchronization checking, appropriate corrections are made in the QSOS_AWARDS table, preventing the creation of a duplicate.

So let's look at what data was in the QSOS_AWARDS table before the synchronization

For station 9J2TJ exists1day differencs- wrong
writing on QSL card

For station DL6NB exists 9 years differencs- wrong
writing on QSL card

For station T88TW exists Differencs is in a
BAND

Why is it so important in databases to avoid duplicates

Each table in MYSQL usually has an index assigned to a specific field. In the case of Loggers, there is a field called QSL number, but it cannot be used, because, for example, Logger32 allows QSOs to be renumbered. Some field that uniquely identifies the QSO is needed. For this, I created a named field

CRC, which is a sting sum of DATE_QSO + TIME_ON + CALL + BAND + MODE fields

For example, an entry

1966-04-0305: 27: 00UW9WF20MCW

means that it is a QSO was do 1966-04-03 at time 05:27:00 with a UW9WF station on the 20M band with CW emission. It is a field indexed in MYSQL, which significantly speeds up the process of searching for QSOs. The emergence of a duplicate means that perhaps the 1st QSO has already been used in some award or, what is worse, has already obtained the AWARDED status.

After synchronization, if there are any differences, a message will appear

Synchronization error message if some exist. I recommend
choosing CANCEL now ie end of the program, restart
and reloading the data, not anymore these
differences should be reported as the corrections
have already been made in the appropriate MYSQL array