Yes, I know, I’m a cripple and I blew it…
Yesterday I worked one of my disgraces (local summits I miss). Unfortunately I entered HA/KD-006 reference instead of HA/KM-006 and uploaded it. When I noticed my fault, I deleted the QSO from my chaser log and entered it with the correct reference via menu point Database, Submit log, Submit chaser entry. However in the list I get from Summits, HA, HA/KM the field “my chases” in HA/KM-006 line remained empty. I deleted it again and uploaded via menu point Database, Submit log, Import chaser TSV/CSV. No change.
What did I do wrong? Or this is a still unknown bug in the program?
I had a problem with my QSO as follows: 01/May/2010,12:45 HA5CQZ/P HA/KM-006 Naszály 14MHz SSB You advised me to wait for the batch processing. I did so.
A week passed by. Now I can see the above QSO in the list “My chaser uniques” but not in the “Summits / HA/KM”. That is, the first program branch displays HA/KM-006 as worked while the second as a not yet worked summit.
Why does the second omit the above QSO? Is it performed less frequently than once a week? Or my original suspect was right and there’s a bug?
In reply to HA5CW:
Same problem here Joska - I worked GW4WSB/P on 01/05/2010 from GW/MW030, GW/MW031 & GW/MW032, they do not show on the Summits GW/MW page but are in my Uniques list & in the Summits “History” lists
Yes, Graham, another week passed by and no change in statistics. Seemingly I still always have HA/KM-006 not yet worked… But I found another bug now…
HB9BAB/p Jürgen activated 2 summits today. Unfortunately he specified a wrong reference (HB/AG-008 instead of HB/AG-009) during the QSO. (Please, floks, note that these sentences are written not in order to blame Jürg, but note a program BUG!)
Unfortunately I uploaded my today chaser QSOs before reading Jürg’s note. I corrected the reference in my log and uploaded it again wondering, what would happend? (I had been working as a programmer for almost 25 years, so I have some kind of intuition, what may cause a porcessing fault…) Yes, it works wrong!
Now I have 2 QSOs with Jürg at 11:53 from 2 different summits, what is impossible. The program did not reject the modified record as an attempt on duplicate upload; did not notice that this is not a new QSO but updating the last one… It simply appedned the modified record to my chaser log.
Of course, I can correct it deleting the record containing a wrong reference, but this is a BUG, I think this it would be worth fixing it in the next patch. (I intentionally did not delete it yet, so that the system manager and programmer friends could see and investigate the not yet manipulated state.)
Of course, I can correct it deleting the record containing a wrong
reference, but this is a BUG, I think this it would be worth fixing it
in the next patch.
I don’t think it has ever been different. You always had to delete the bad reference. You may consider it a bug, I don’t really.
I consider it more important to re-establish the link between the SOTA-DB and the SOTAWATCH-DB, as stated by DC7CCC in another thread, or re-establishing the “*” to actually confirm the QSO.
Most likely people are pretty busy working behind the curtain.
Most likely people are pretty busy working behind the curtain. <<
Hi Norby!
I don’t doubt their efforts. However tastes are different. As far as I can concern, if date + time + band + mode + callsign in a record to be uploaded are identical to those in a record formerly uploaded, is a reasonable and sufficient reason not to append the new one but overwrite the old record with it. This would be a much more elegant solution, I think.
Re-eEstablishing the link between DBs is another reasonable and useful point. (Unfortunately, suffering from lack of time, I did not read Mario’s note you referred to.)
