Hi ,
today, I worked B0/BA4TB via QO-100. I entered the QSO, and it automatically recognizes the DXCC country as BV (Taiwan). The real DXCC country is China (BY), which can be confirmed with QRZ.COM.
I clicked on "Edit QSO" and tried to correct the DXCC country in 2 different ways, both of them failed:
1. I manually entered "BY" in the DXCC ref. field and then saved the QSO
2. I klicked on the button ... next to the DXCC ref field, selected BY, clicked on "apply" and saved the QSO.
Whatever I do, the field "dxcc ref" always sets itself back to BV.
I exported this one QSO as ADIF, opened the file with an editor, replaced the DXCC Country by China, changed the DXCC entity code to 318, and imported the QSO. Result: CQRLog still indicates the DXCC as Taiwan.
I am running CQRLog 2.5.2 on Kubuntu 20.04.
73 Jens HB9EKO
HI Jens!
Yes. If cqrlog's DXCC data says it is Taiwan it does not let you to save any other DXCC.
Only way is to change DXCC directly in database with sql command, (Qso list/Filter/SQL console)
Write line:
update cqrlog_main set adif=318 where callsign='B0/BA4TB'
to upper part of sql console and press leftmost big green arrow. Close sql console and view qso again.
--
Saku
OH1KH
Hi Saku,
thanks a lot, it worked.
Is editing the DXCC entity disabled intentionally? I would expect that I can manually override automatic entries, like for example the name field when it's auto-filled after a qrz.com query. I don't find SQL commands very comprehensive. On the other hand, it was the first time in 12 years that the database was wrong...
73 Jens HB9EKO
HI !
At the moment it is coded so that you can not save manually changed DXCC.
As the special and "weird" callsigns amount is growing it is hard to keep county and resolution files up to date. In "good old times" it was different. Callsigns were always clear and you could even define states from prefixes. Not any more.
So it is good question should user edited DXCC be saved as is?
--
Saku
OH1KH
Hi Saku,
In my opinion, DXCC should be editable for single QSO entries in the QSO database only. If country files were updated with the correction, then all non-exceptional prefixes of the DXCC with the one exception would consequently cause the entry of another exception etc. The country lists etc. are good as they are for probably >99% of all QSO entries, and for the rare cases where it's really necessary to edit the DXCC, I would assume that the user knows what he or she is doing.
73 Jens HB9EKO
I'm new to this group, and fairly new (~10 weeks) to CQRLog. I have to say, I love it.
I too have an issue with wrong DXCC, and I have to agree with Jens, DXCC entity should be editable on a per-QSO basis. Changing it in the DXCC database will create other issues. A case in point: I just worked KH2AR, located in Memphis, TN, grid EM55, but CQRLog is artificially inflating my DXCC count from 98 to 99, counting this station as being located in Guam based on the call sign. If I were to change KH2 in the database from Guam to United States, then i will never be able to get credit for Guam should I ever happen to work a station that is actually located there.
Using the grid square to determine DXCC might appear to be a solution, but it will not work, because some grid squares (my own included) span more than one country.
I haven't yet tired to upload this log entry to LoTW, so I don't know if LoTW will catch the error and correct it, or if I will achieve DXCC prematurely and illigitimately. I suppose if i hurry up and work a station that is truly located in Guam, my problem will go away, but that's iffy.
Anyway, I hope this small contribution is useful!
Bill
Hi Bill,
>>I haven't yet tired to upload this log entry to LoTW, so I don't know if LoTW will catch the error and correct it, or if I will achieve DXCC prematurely and illigitimately.
Now that you raised the issue, you made me curious. I logged into LotW and checked some QSO details. For QSOs that are not QSL, there is a DXCC entry for my own station, but for the worked station, there is just the call, date/time, mode and band/frequency. Only QSO records with QSL contain SCXX, zones and grid locator.
So the information for DXCC or other awards is obviously based on the other station's certificate and not on what you upload.
73 Jens HB9EKO
Good point Jens! I should have realized that LoTW is going to rely on the other station's signed upload for it's QTH, not on my upload. And since LoTW only cares about confirmed contacts for award purposes, there is no danger of my falsely achieving DXCC based on an incorrect DXCC entity in my log. So the only real issue then is the Worked count shown in my own CQRLog, which per-QSO editing of DXCC entity would solve. Not sure though what other issues, if any, allowing such edits might create though. I can't think of any, but I'm not a coder...
Bill
The China problem (B0/BA4TB etc.) is now fixed.
The problem with calls assigned to USA and possessions is impossible to fix, the location is now (~ last > 10 years!) NOT RELATED to the prefix. So you can work KH6 from New York, AL0HA is KH6 (Aloha ... :-), KL7 may be Puerto Rico, KP4 on Guam (KH2) etc. There are two options:
1) Ask Joe Biden to force the FCC to clean the mess,
2) Press F11 any time you are working a station in US & possessions. This will use their daily maintained database to update the location, the logger responds with correct DXCC entry etc. This works, as far as I know.
It worked!!! (Pressing F11 that is, not calling Joe.) Thanks Martin!
And it doesn't necessarily have to be when you're working the station; my errant DXCC entry is now 3 days old. I clicked "Edit QSO", pressed F11, clicked "Save QSO", and my DXCC count is now back to where it should be!
Since I haven't been using the program all that long, it won't be an onerous task for me to go back through all my USA and posessions QSOs and fix them in this manner, in case there are any others errantly recorded. I'm not currently working toward WAS, but if I eventually do so, it will be important to have the correct state recorded. Then I just have to remember to press F11 while working such stations going forward. (That's what the yellow sticky notes on my monitor are for, hi.)
73, and thanks for the help Martin and Jens
Bill
Bill