DXCC and DXCC CFM in QSO window wrong (and going down...)

3 posts / 0 new
Last post
DB2MJ
DXCC and DXCC CFM in QSO window wrong (and going down...)

I'm using cqrlog for a few years now, currently Ver 2.0.5 (001) on Linux Mint 17.3. Recently I noticed something disturbing: the number of DXCC countries and DXCC CFM went down... additionally, the DXCC statistic says 138 DXCC confirmed by LotW, but lotw.arrl.org says I have 140 confirmed DXCC. Obviously, something is wrong. To find out, I dumped the complete database (cqrlog001 and cqrlog_common), got my logs from lotw and examined the data.

I found these entries with the first try:

+-----------+----------+------+
| callsign | cqr_dxcc | lotw_DXCC |
+-----------+----------+------+
| 5B4PRC | TF | 5B |
| 9G5AM | OM | 9G |

Both calls are the only ones with this particular dxcc entity. Both have something in common: I recently ordered QSL cards via OQRS and did an edit of the CQRLOG-entries (added the OQRS order data to the comment-field). Somehow the dxcc-field entry of this record got mixed up. When I recalled these records and did an "edit QSO", the wrong DXCC ref. entries changed automagically to the correct values and "save QSO" set them correctly.

Any idea how this can happen? And how do I check my several thousand QSO records? It would be nice (and easy) to have a program that reads a callsign and outputs the number in the "adif" field. This could be used to check the records automatically. CQRLOG must have this builtin, because entering the callsign sets the DXCC window entry automatically.

Martin DB2MJ (and database programmer in another life...)

ok1rr
ok1rr's picture
Re: DXCC and DXCC CFM in QSO window wrong (and going down...)

Although I have in CQRlog > 127 000 QSO with 345 DXCC countries I can't reproduce your problem... Be more specific, please. What about previously used loggers - or did you all the job in CQRlog? CQRlog puts the country and ADIF number into log. What do you need more?

DB2MJ
Re: DXCC and DXCC CFM in QSO window wrong (and going down...)

Unfortunately, I can't reproduce it easily. I wrote enough software to know that a reproduceable bug is a fixed bug...

I just noticed that my DXCC/DXCC CFM counter went down one each and examined the database for the reason by comparing the adif exports cqrlog produces at closing. The reason was that one LOTW-confirmed QSO suddenly had a different (wrong) DXCC entry in the record. I had only one QSO with this DXCC entity, so the counters went down. It is entirely possible that there are other records in the QSO database with a changed (wrong) DXCC in it, but this is only visible if the DXCC (and possibly the DXCC CFM) counter changes. If its the second, third... QSO with a already counted DXCC you'll only see that by examining this specific record.

There are two ways to find more about it: I'm going to switch on SQL logging in the database. When I see the effect the next time I can see what SQL statment did the change. I did a download of my LotW log from ARRL and compared the DXCC field there with the same field in my cqrlog-database. This gave me 3 more wrong DXCC entries in cqrlog001.cqrlog_main.

When I enter a new QSO, cqrlog automatically sets the DXCC field, so it should be not to difficult to check the integrity of the database by reading the QSO table and compare the computed DXCC by the saved DXCC. Any differences must be checked manually, but this would be easy. The problem is finding them...

Martin DB2MJ