In the QSO archive I clicked 'Search', enabled update and selected entries. Then 'Field update' was clicked and 'distance' selected. After clicking 'Update' the complete data disappears.
In the Main window / 'Recent QSO' no entry is shown too after refresh. Only in the left down corner I see the correct number of QSOs.
Then a new database has to be created and the last adi file imported.
This happened some times in a row. Operator error, corrupt adi file or bug?
73, Willi DJ6JZ
data loss by distance calculation?
-
G4POP
- Log4OM Alpha Team
- Posts: 10808
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: data loss by distance calculation?
Hi Willi,DJ6JZ wrote:In the QSO archive I clicked 'Search', enabled update and selected entries. Then 'Field update' was clicked and 'distance' selected. After clicking 'Update' the complete data disappears.
In the Main window / 'Recent QSO' no entry is shown too after refresh. Only in the left down corner I see the correct number of QSOs.
Then a new database has to be created and the last adi file imported.
This happened some times in a row. Operator error, corrupt adi file or bug?
73, Willi DJ6JZ
Just tried to emulate this and everything worked fine.
Please email me you sqlite file so that I can try to find the problem
73 Terry G4POP
-
G4POP
- Log4OM Alpha Team
- Posts: 10808
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: data loss by distance calculation?
I cannot understand what happened to Willi’s data but I have some theories which we will explore! However I believe the problem was in two parts
Part one.
Willi stated in his post "After clicking ‘Update’” but when executing a ‘Log Check up’ the button to click is “Execute Checks”
I suspect that there we some values in the ‘Field to update’, ‘value’, 'Query' and/or ‘Clear field’ and the “Update QSO distance/bearing” was checked when the ‘Update’ button clicked which caused the data to be corrupted.
When Willi forwarded me his apparently empty sqlite database I found that nothing had been lost when the file was viewed with an SQLite editor, however the data did not show in Log4om.
Clearly we need to explore what happened in more detail and I am going to ask Daniele to look at the file and also disable the “Update” button when any box is checked in the “Log check up” panel.
This is a lesson to be learned so please study the screen shot below.
Part two
When I inspected Willi’s logbook I found that there were very few values in the “My Grid square” field and this is one of the values that we use to calculate the distance and heading, so the first thing I needed to do was update his grid square for all QSO’s using the QSO archive manager.
Additionally hardly any of the entries had a grid square for the stations that he had worked, this is the other value that is required to calculate distance and heading, so again using the QSO archive manager I updated this information by selecting the QSO’s without a grid square and then I clicked the ‘Update info’ button to update them all using the QRZ bulk lookup.
Many of the original entries had the distance and bearing set to an ‘O’ (Not a zero! the letter ‘O’) and this caused me some head scratching! So these fields had to be emptied!
Having updated the information as above I was then able to use ‘Field update’ and then “Log check up” to calculate the distance and bearings. (I CLICKED "EXECUTE CHECKS"
)
Willi’s updated/repaired logbook was then emailed back to him.
Part one.
Willi stated in his post "After clicking ‘Update’” but when executing a ‘Log Check up’ the button to click is “Execute Checks”
I suspect that there we some values in the ‘Field to update’, ‘value’, 'Query' and/or ‘Clear field’ and the “Update QSO distance/bearing” was checked when the ‘Update’ button clicked which caused the data to be corrupted.
When Willi forwarded me his apparently empty sqlite database I found that nothing had been lost when the file was viewed with an SQLite editor, however the data did not show in Log4om.
Clearly we need to explore what happened in more detail and I am going to ask Daniele to look at the file and also disable the “Update” button when any box is checked in the “Log check up” panel.
This is a lesson to be learned so please study the screen shot below.
Part two
When I inspected Willi’s logbook I found that there were very few values in the “My Grid square” field and this is one of the values that we use to calculate the distance and heading, so the first thing I needed to do was update his grid square for all QSO’s using the QSO archive manager.
Additionally hardly any of the entries had a grid square for the stations that he had worked, this is the other value that is required to calculate distance and heading, so again using the QSO archive manager I updated this information by selecting the QSO’s without a grid square and then I clicked the ‘Update info’ button to update them all using the QRZ bulk lookup.
Many of the original entries had the distance and bearing set to an ‘O’ (Not a zero! the letter ‘O’) and this caused me some head scratching! So these fields had to be emptied!
Having updated the information as above I was then able to use ‘Field update’ and then “Log check up” to calculate the distance and bearings. (I CLICKED "EXECUTE CHECKS"
)Willi’s updated/repaired logbook was then emailed back to him.
- Attachments
-
- Log checks.jpg (135.97 KiB) Viewed 3919 times
73 Terry G4POP
Re: data loss by distance calculation?
Good morning Terry,
thank you very much for checking my database, this was an unexpected fast overnight service!
If the import adifs (from eqsl and from jt65-hf-hb9hqx-edition) should be helpful for further investigation, please let me know.
From the visual layout of the "Field Update" window I got the impression that the buttons "Backup" and "Update" are related to the "Field to update" menu, while the "Execute checks" button is related to the 6 checkboxes below.
These boxes were unchecked during the attempt to update the distance field, although all entries were checked by the "Update info" command before already, to add missing grid squares.
So when the problem occured, I did not use the checkbox "Update distance/bearing", but the scrolldown menu "Field Update" (distance) and the button "Update".
A proposal regarding the import of eqsl adifs: As described earlier, the EQSL outbox adif has correct QSO start times, but no end times. The inbox has wrong start times (these values are in fact the end times), no values as end time.
So because of different start times L4OM cannot recognize duplicates, and importing both files will lead to a lot of double entries.
Could this be avoided by a check during import, whether a call was worked on the same band/ in the same mode +- 30 minutes of an existing entry?
vy 73,
Willi, DJ6JZ
thank you very much for checking my database, this was an unexpected fast overnight service!
If the import adifs (from eqsl and from jt65-hf-hb9hqx-edition) should be helpful for further investigation, please let me know.
From the visual layout of the "Field Update" window I got the impression that the buttons "Backup" and "Update" are related to the "Field to update" menu, while the "Execute checks" button is related to the 6 checkboxes below.
These boxes were unchecked during the attempt to update the distance field, although all entries were checked by the "Update info" command before already, to add missing grid squares.
So when the problem occured, I did not use the checkbox "Update distance/bearing", but the scrolldown menu "Field Update" (distance) and the button "Update".
A proposal regarding the import of eqsl adifs: As described earlier, the EQSL outbox adif has correct QSO start times, but no end times. The inbox has wrong start times (these values are in fact the end times), no values as end time.
So because of different start times L4OM cannot recognize duplicates, and importing both files will lead to a lot of double entries.
Could this be avoided by a check during import, whether a call was worked on the same band/ in the same mode +- 30 minutes of an existing entry?
vy 73,
Willi, DJ6JZ
-
G4POP
- Log4OM Alpha Team
- Posts: 10808
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: data loss by distance calculation?
Willi,
We already use a 30 minute time window when merging to fit with LOTW imports, the real fix is not to rely on an eQSL import for anything other than QSL verification. EQSL is known to have many shortcomings with regard to missing data.
The drop down Field update requires a value to be inserted into the value box to the right, it is not for calculating data in a field it is just for bulk update of QSO information by manual insertion of information.
We already use a 30 minute time window when merging to fit with LOTW imports, the real fix is not to rely on an eQSL import for anything other than QSL verification. EQSL is known to have many shortcomings with regard to missing data.
The drop down Field update requires a value to be inserted into the value box to the right, it is not for calculating data in a field it is just for bulk update of QSO information by manual insertion of information.
73 Terry G4POP
