Hi!
I have noticed that sometimes a QSO has the wrong DXCC reference. In those cases I have just opened the QSO , edited the DXCC ref and saved it just thinking I may have messed something up when entering the QSO.
But now I noticed that 2 or 3 QSOs in the QSO list had wrong DXCC-refs. I re-built the statisticts and suddenly there the references changed, but to other wrong references. I corrected two of them, saved the QSOs and run the re-build of stats and one corrected QSO turned to the wrong DXCC again.
For example I have HC2AO in the log, confirmed by LoTW. The logger says its a ZB2. I correct it manually by choosing HC in the DXCC-dropdown list and save. It looks OK. Then I update statistics. This time it shows up as EA9!
Any clues on what could cause this?
I can send my ADIF.
I use the 1.7.4 release and always take the latest DXCC-list if available
Best regards, Mikael SM6VJA
EDIT:
I exported the ADIF and imported it to a new log and the problem seems to have gone away.
The old log is consistently throwing around a few DXCC-references randomly in the log when re-building DXCC stats. The database must have gone nuts in some way.
Anyway, I'll keep an eye on this if it appears again and then try to capture what made it happen.
Best regards, Mikael SM6VJA
Sun, 2014-06-08 20:34
#1
Random DXCC reference after DXCC-rebuild?
Hello all,
After a GM7V qso correctly saved, the dxcc prefix GM is seen in the qso window.
It becomes a dxcc prefix ZF when the dxcc rebuilt function is used ?
So I edit this qso and moves through with tab, that gives the correct GM dxcc prefix appears again.
Then I sort all GM and rebuilt dxcc, which does not modifiy the GM to ZF.
I enter a new qso to eliminate any effect due to the first or last qso in DB... No changes, the M always changes to ZF when Dx rebuit is used.
Any idea ?
73 Laurent F6GOX
HI Laurent!
Must be a corrupted log database.
As a test:
Fix Prefix to GM, do not rebuild DXCC. Export all qsos as adif with every item selected for export.
Go to "Open database" and create fresh new log. Import adif to that log.
Does the problem exist in this new log?
--
Saku
OH1KH
Hello Saku,
Good point. This problem does not exist with the new log database.
Note that in the corrupted log, the last qso saved - not the GM which is now not changed - is always the only qso transformed to ZF prefix after "rebuild dxcc" ?
73 Laurent F6GOX
Hi Laurent!
Have you tested "Open database/utils/repair database" for corrupted log?
It does not make wonders but is easy to test.
--
Saku
OH1KH
Hi Saku !
1. "Have you tested "Open database/utils/repair database" for corrupted log?" => Yes without success.
Then I delete all the 53.674 qso in the "corrupted" database, except 3, by select and delete all qso, means only 500 by 500... So it takes some time.
As I only keep 3 qso, I have test the "rebuild dxcc" with no effect on the dxcc prefix. I do the same with only one qso: no effect.
2. Then I reload the 53.000 qso, remove dupe, test "rebuild dxcc" and obtain again the dxcc prefix change, only the last saved qso changes its dxcc prefix. Note this time it is not replace by ZF but by KL...
So I decide to delete all the qso by 10.000 and make the "rebuild dxcc" test every 10.000 deleted qso : The first qso at the top of the "window/qso list" always changes his prefix for 49671, 39674, 29674, 19674, 9674 qso... but not for 674 qso !
I reload the file and do the same experience now from 9674 by 500 qso deleted : Change always continue to 8174 qso. So that means between 8674 and 8174 qso, something is wrong...
3 .Then reload all the log, remove dupe, and filter qso between these two date limits... "Rebuild dxcc" changes dxcc prefix at the bottom date qso. Even with one date/qso selected by filter, "rebuild dxcc" runs overall the entire database and not only the filter selected qso, so that changes the dxcc prefix even for on selected qso.
4. So as there is filter/sql console in the menu , could we try to repair this data base via the sql console ?
Tnx.
73 Laurent F6GOX
Hi Saku,
Somethings seems wrong again with the "new" database... after close it and reload again same adif file in a new log, rebuild dxcc gives same dxcc error...
So do I probably need SQL tools to repare it ?
73 Laurent F6GOX
Hi Saku !
After uses the "non corrupted" log, I tried to filter a dxcc. It works but there is also the message window below appears . So I abort...
TMySQL57Connection : Error executing query: Unknown column 'dxcc_ref' in 'where clause'.
Press OK to ignore and risk data corruption.
Press Abort to kill the program.
At your opinion ?
73 Laurent F6GOX
Hi Laurent!
I think I have found a bug from DXCC rebuild code. Thanks for reporting!
It happens now so that when you rebuild DXCC it goes through all qsos and if it finds a qso with DXCC status different that what is in latest downloaded DXCC info it changes that qso's DXCC information.
Now the bug causes this information fix to happen to latest worked qso, not to the one it should affect.
Every time a qso that needs fixing is found the fix appears always to latest worked qso.
So finally when rebuild is over the latest worked qso has DXCC status of a qso that was latest that needed DXCC change by rebuild.
--
Saku
OH1KH
Hi Laurent!
"
So I decide to delete all the qso by 10.000 and make the "rebuild dxcc" test every 10.000 deleted qso : The first qso at the top of the "window/qso list" always changes his prefix for 49671, 39674, 29674, 19674, 9674 qso... but not for 674 qso !
"
You diid mean that with 674 qsos all is ok, but if there are more then DXCC will get corrupted?
Did I understand ok?
Or is there a change in DXCC at qsos 49671, 39674, 29674, 19674, 9674 and so on ?
I made a test with my 9994 qsos and the last one qsos DXCC ZS changed to KP2 after rebuild DXCC statistics. I did not walk through all qsos to see are there more changes somewhere.
So it seems that there is a bug in somewhere in the rebuild process.
--
Saku
OH1KH
Hi Saku
Good news.
I sort log file 10.000 by 10.000, test it and then decrease the size to one by one and have found 3 errors qso !
WL7 as W, WP4 as W and NP2 as W...
After deleted theses qso, testing rebuild dxcc the base works well to 47173 qso...
I need time to complete test the base to 53674 qso...
I also remark that time to time, not all the time..., after reload a file, rebuild dxcc gives a error but rebuild again makes the good correction and be stable...
More news later !
73 Laurent F6GOX
Also,
after re-enter these deleted qso, the base gives me the good dxcc prefix, ITU and WAZ zones.
The 47173 qso file now works well under rebuild dxcc test.
73 Laurent F6GOX
Hi Laurent!
Note that NP2 may be W. Test with NP2AA. DXCC is W and qth Florida. Same may be with other US calls. They can keep their callsing when they move qth.
Can you compile cqrlog from source? Or try to run ready compiled binary?
I would like to hear results with fixed dxcc rebuild. My opinion is that it is more or less random how rebuild ends with current cqrlog version as I told in message #9 https://cqrlog.com/comment/8960#comment-8960
In addition what I said the wrong fix appear to "last worked qso" it may also be "last viewed/edited" or the top qso of the block of QSO list viewed qsos (it loads them in blocks, not entire log content at one go)
Other solution would be that you send the original adif file to me for running it through fixed rebuild and then I return it back to you for check.
--
Saku
OH1KH
Hi Saku,
I agree with you that NP2## and WP4### could be W.
I just remark that delete these two qso has modified the behavior of the rebuild dxcc function in the good direction.
I send you two files to test it hem: the 47173 good file and the original 53674 wrong file "corrupted".
It seems there always is somethings wrong in the last 6501 Qsos. I am trying to find it...
73 Laurent F6GOX
Hi Laurent !
Did you send those files? None received here.
My address is ok in qrz or HamQth.
In case they are very big size please zip them and send only one in one message.
Do not waste your time with new rebuilds. There is a bug and it must be fixed before it works.
--
Saku
OH1KH
Hi Saku,
In the entire corrupted database file but with the three deleted WL7, WP4 and NP2 qso, rebuild gives KH6 fo the last saved qso.
Sort KH6 and find a KH6 with W prefix.
I delete KH6VM and rebuild dxcc : KP2
Sort KP2, delete NP2/B/4, rebuild : KP2
Sort NP2, delete NP2GG, rebuild : KH2
Sort KH2 and NH2, all qso correct dxcc...
rebuild three times, same results KH2...
Now ?
73 Laurent F6GOX
Sort KH2 and delete all KH2 qso
Rebuild : KL7
Sort AL7, KL7, NL7, WL7 qso correct dxcc
Delete all KL7
Rebuild : KL...
73 Laurent F6GOX
HI Saku,
Files resent to QRZ email address.
73 Laurent F6GOX
Good afternoon Saku,
First warmfull thanks : it works !! :-)
I do your process. Even before to cry victory, I load, sort qso from many log.adi files and even the LoTW database confirmed qso...
Now I have 53689 qso in the log and do "rebuild dxcc" has no trouble...
Congrats for all.
Best 73
Laurent F6GOX
73 Laurent F6GOX