Hello

I'm not sure if this is useful information, but something that I found interesting. This could be a purely local issue, but since I'm running a GIT pull I thought I'd mention it just in case.

I'm running cqrlog Ver:2.6.0 (001) Gtk2 Date:2022-07-05 compiled locally. My local system is Debian Bullseye, fully up to date. I run one copy of cqrlog on my FT8 computer, and another on my my main computer where the database is. Both copies showed the same behavior.

I noticed problems with a particular QSO with CX1RL. cqrlog was running with WSJT-X in remote mode and I worked CX1RL on 15m FT8 when the entry was initially added to the database.

I had no contacts with Uruguay before, so I noticed when my DXCC worked bumped up one right after I made the contact.

Several days later, CX1RL updated his LOTW, and cqrlog picked up the change. I saw the qsls_r column change to "L."

But my DXCC confirmed count remained the same! As CX1RL was an ATNO for me, it should have incremented by one.

I uploaded to clublog and clublog said I had no confirmed contacts with Uruguay. Looking closer, it said I had one unconfirmed contact with CX on 40m.

I filtered my log to find CX contacts, and found that W7BR, a 40m SSB contact, had a dxcc_ref entry of CX. CX1RL had a dxcc_ref entry of W. So I edited W7BR back to W, and saved the QSO.

I edited CX1RL back to CX and saved the contact.

Then I rebuilt DXCC statistics. My DXCC confirmed entries remained the same.

I looked at CX1RL, and the dxcc_ref entry was "KL!" (W7BR was still "W.")

So I edited CX1RL again, and changed it to CX. This time the CX change took, and CX1RL remained CX.

But my DXCC confirmed count remained the same, and my DXCC worked count had decremented by one.

Looking at the DXCC chart I saw that I know had some 62 CX contacts. Using the filter, I searched for log entries with dxcc_ref of CX, and found all of my KLs were now CXs.

I edited CX1RL back to KL, and that also moved all of my KLs back to KL.

I attempted to fix this with the SQL console. I ran the following:

UPDATE view_cqrlog_main_by_qsodate SET dxcc_ref = 'CX' WHERE callsign LIKE 'CX1%'

When I did that, all of the KLs also toggled back to CX.

(You may ask why I was updating the view! Normally, the view_cqrlog_main_by_qsodate is an updatable view. I use it for little chores like updating the qsl_s field for contacts I already have a card for when I don't want to print a new card, etc.)

At this point, I could move CX1RL from CX to KL and back, and it would affect all of my KL contacts at the same time. It was very strange, and I was happy I had adif backups of my log. I have no idea how this relationship between CX and KL was established, except that my home call is a KL, so that may be part of the mystery.

I eventually resolved this by logging into mariadb with the cqrlog account directly, and setting the adif field directly:

UPDATE cqrlog_main SET adif = 144 WHERE callsign like 'CX1%';

At that point, everything saved correctly and uploaded correctly.

NOTES:

I noticed that when I was flipping my KL contacts to CX and vice versa, when I refreshed my clublog data, ONLY CX1RL WAS UPLOADED. So I think this is an issue with the views, not the raw database. cqrlog did not think that my KL contacts were updated, even though the view was showing them flip from CX to KL.

Even though only CX1RL was uploaded, it had several clublog uploads, not just one. As if one edit made several updates to the QSO. Refreshing DXCC statistics would also generate more updates than I was expecting.

The GUI edit QSO was somehow affecting the view for QSOs not in the edit window.

The GUI SQL console was somewhow affecting the view for QSOs that should not have been in the affected rows. A SELECT statement in the GUI SQL console also returned my KL contacts when I searched for callsign LIKE 'CX1%'

Editing SQL directly, using mariadb, worked. But in that case, I was editing the cqrlog_main table, and not the view.

Anyway, I'm not sure if this is an issue that anyone else can duplicate! It is very strange, and I've never seen cqrlog have such odd database behavior before. (But again, I think that only the view was behaving strangely.)

73,

James
KL2ZZ