Hi!
I'm running cqrlog 2.4.0 (001) on Linux Mint 19.3. Database is a Mariadb on a remote FreeBSD server (Server version: 10.3.14-MariaDB FreeBSD Ports).
When running Statistics->DXCC Statistics->Rebuild DXCC-Statistics from the QSO-window the latest QSO table entry, fields "itu", "waz" and "cont" will get changed:
--------snipp-----------
db2mj@birdland:/tmp# diff dump1 dump2
4053c4053
< INSERT INTO `cqrlog_main` VALUES (7501,'2020-02-01','16:09','16:10','9G2HO',18.1020,'FT8','-02','-06','','','N','','','','',46,35,'JJ06','JN49rn','','','FT8 Sent: -02 Rcvd: -06',424,'17M',0,1,'9G2HO','','2020-02-01','2020-02-01','Y','L','AF',NULL,NULL,'','','','','','Y','2020-02-01','',NULL,NULL,'','','','','','','');
---
> INSERT INTO `cqrlog_main` VALUES (7501,'2020-02-01','16:09','16:10','9G2HO',18.1020,'FT8','-02','-06','','','N','','','','',28,14,'JJ06','JN49rn','','','FT8 Sent: -02 Rcvd: -06',230,'17M',0,1,'9G2HO','','2020-02-01','2020-02-01','Y','L','EU',NULL,NULL,'','','','','','Y','2020-02-01','',NULL,NULL,'','','','','','','');
5150c5150
< -- Dump completed on 2020-02-02 7:53:44
---
> -- Dump completed on 2020-02-02 7:54:08
--------snipp-----------
This wreaks havoc with your DXCC-statistics, especially if the latest entry is a new country :-(
The fields that are changed are derived from the call sign, so it should be possible to correct the whole database right at a later date.
I suspect there are a few changed entries in my database, because the DXCC-stats from cqrlog are different from these at LOTW for some time. Not impossible to find for LOTW entries, but hard to do for QSL-card only. Should be easy to correct if I had a program that takes a call sign and returns the correct values for "itu", "waz" and "cont". The rest is easy with a little perl programming. However, I've yet to find one that does that.
Martin DB2MJ
Hi Martin!
You say the latest entry will be changed.
Does it happen always (now when you know it happens you can perhaps replay it easily somehow)?
Are the values that last entry will get same as previous qso before in the log has had?
Or are they values that had been at last NewQSO entry before running rebuild?
(I.E. thinking about some variables not correctly cleared when NewQSO has been left for running DXCC rebuild).
--
Saku
OH1KH
I tried it again. Entered a QSO with an imaginary callsign (9E5XA) and rebuild statistics. Same result, the three fields were changed. The changed record had the largest id:
+----------------+------------+---------+----------+--------------+---------+-------+----------------------+--------+-------------->
| id_cqrlog_main | qsodate | time_on | time_off | callsign | freq | mode | rst_s | rst_r | name >
+----------------+------------+---------+----------+--------------+---------+-------+----------------------+--------+-------------->
| 7504 | 2020-02-03 | 16:51 | 16:51 | 9E5XA | 7.1000 | SSB | 44 | 55 | >
| 7503 | 2020-02-02 | 12:11 | 12:11 | EA8JK | 21.2050 | SSB | 59 | 59 | Manuel
This is what I found in the query log of the Mariadb database. Doesn't quite look as if it's intentional...
187766 Query START TRANSACTION
187766 Query select id_cqrlog_main,qsodate,callsign,adif,qso_dxcc from cqrlog_main
187766 Query START TRANSACTION
200203 17:55:04 187766 Query UPDATE cqrlog_main SET adif=294,waz =14,itu =27,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=294,waz =14,itu =27,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=230,waz =14,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=1,waz =05,itu =04,cont='NA' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=54,waz =16,itu =29,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=230,waz =14,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=212,waz =20,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=214,waz =15,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=446,waz =33,itu =37,cont='AF' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=230,waz =14,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=144,waz =13,itu =14,cont='SA' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=279,waz =14,itu =27,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=15,waz =17,itu =30,cont='AS' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=1,waz =05,itu =09,cont='NA' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=275,waz =20,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=230,waz =14,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=219,waz =36,itu =47,cont='AF' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=504,waz =15,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=0,waz=null,itu=null,cont=null WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=336,waz =20,itu =39,cont='AS' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=294,waz =14,itu =27,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=391,waz =21,itu =39,cont='AS' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=288,waz =16,itu =29,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=291,waz =05,itu =08,cont='NA' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=145,waz =15,itu =29,cont='EU' WHERE id_cqrlog_main=7504
187766 Query UPDATE cqrlog_main SET adif=230,waz =14,itu =28,cont='EU' WHERE id_cqrlog_main=7504
187766 Query COMMIT
187766 Query ROLLBACK
BTW, I think the values of the last update are the values of my station. The line above it aren't the ones from the second-to-last record in cqrlog_main.
If it would be helpful, I'd put a database dump of my data in the cloud for you to analyze.
73,
Martin DB2MJ
Hi Martin!
I did a test with same call as you. Added a qso 9E5XA.
Then dumped itu waz,cont from 3 last qsos.
Then made rebuid of dxcc statistics
Then dumped again itu,waz,cont form 3 last qsos.
I can not see difference. Did I misunderstood something?
MariaDB [cqrlog007]> select id_cqrlog_main,itu,waz,cont from cqrlog_main order by id_cqrlog_main desc limit 3;
+----------------+------+------+------+
| id_cqrlog_main | itu | waz | cont |
+----------------+------+------+------+
| 279 | 48 | 37 | AF |
| 278 | 52 | 36 | AF |
| 277 | 11 | 7 | NA |
+----------------+------+------+------+
3 rows in set (0.000 sec)
MariaDB [cqrlog007]> select id_cqrlog_main,itu,waz,cont from cqrlog_main order by id_cqrlog_main desc limit 3;
+----------------+------+------+------+
| id_cqrlog_main | itu | waz | cont |
+----------------+------+------+------+
| 279 | 48 | 37 | AF |
| 278 | 52 | 36 | AF |
| 277 | 11 | 7 | NA |
+----------------+------+------+------+
3 rows in set (0.000 sec)
Have you tried to make fill adif backup from your log. Then create a new empty log and import your backup to new log and test this rebuild with the new log.
Does that act similar way?
--
Saku
OH1KH
I made an export into an ADIF file and imported it into a new log. Problem went away... (at least as far as I can see). Dumps don't show change.
So, there is some inconsistency in my log DB. Anyway, I switched to the new log and will watch for problems. Thank you for your help!
Martin DB2MJ
Hi Martin.
Thanks for info.
I try the same to see if I can make it happen here.
Just when time permits.
--
Saku
OH1KH
Hi Martin.
Thanks for info.
I try the same to see if I can make it happen here.
Just when time permits.
--
Saku
OH1KH