Duplicates in New Sota DB

Hi,

Trying to upload these 2 records and getting an error about duplicates, there are no
duplicates for these 2 records.
Please advise.

Callsign
Summit
Date
Time
Band
Mode
Other Callsign
Other Summit
Comment
Is S2S?
Is Chaser Entry?
Duplicate?
KN4VSI
W4G/HC-036
25/12/2019
21:25
144MHz
FM
KE4Y
:heavy_check_mark:
There are errors in your file - please correct them and try again

Callsign
Summit
Date
Time
Band
Mode
Other Callsign
Other Summit
Comment
Is S2S?
Is Chaser Entry?
Duplicate?
KN4VSI
W4G/HC-036
25/12/2019
21:23
144MHz
FM
WG4I
:heavy_check_mark:
There are errors in your file - please correct them and try again

The Database shows and activation already entered on that date.

I seem to recall it only accepts one activation upload for a day and that you will need to delete any entry already made and upload all the QSO’s in one go.

So am I understanding correctly, that I need to delete the 3 entries that are there, then upload 5 at once? I can do that, but it’s a bit ridiculous not to be able to upload more than one log file for a day, especially if you’ve activated multiple summits in one day, and logged them in separate logs. IMHO

I’ll try what you said by deleting entries for that day and uploading all at once.
.\

I deleted the existing entries, and went to upload a fresh ADIF log with all 5 entries in it, after checking with ADIF Master, and now its worse. Showing 3 time errors (and I downloaded the file from SOTA db, so it apparently doesn’t like its own data), those times are from the logging app, and also from what I downloaded from the SOTA DB, so who is it possible the time is wrong?

KN4VSI
W4G/HC-036
25/12/2019
21:45
144MHz
FM
AE1JS
W4G/NG-017
:heavy_check_mark:
KN4VSI
W4G/HC-036
25/12/2019
21:25
144MHz
FM
KE4Y
KN4VSI
W4G/HC-036
25/12/2019
21:23
144MHz
FM
WG4I
There are errors in your file - please correct them and try again

Hi Michael,
The new database seems to still have some bugs that need fixing. I have reported a few of them to the database manager Andy @MM0FMF and he told me they are working on them together with Andrew @VK3ARR.
I remember having a similar problem to the one you are describing here and I realised that in spite of receiving those error messages, the record I was trying to introduce was actually received and incorporated to the database. Can you check whether the files you are trying to upload and the database is giving you those error messages for are actually in the database now?
In my experience, some things like these not working properly on the new database can still be done properly with the old database.
Let me show you a couple of examples of what I’m telling you now by showing you two of my PMs to Andy MM0FMF:
PM #1:
I’ve noticed a wrong behaviour on the newsotadatabase (newDB) on something that the sotadatabase (oldDB) is handling perfectly. This is under a very specific situation which I’m going to describe:
I did SOTA chasing today and logged everything with SAISIE SOTA program. At one point, I decided to save my log and upload my .csv chaser log to the database. Later, I chased one more activator and added this last QSO to my previous chasing log on SAISIE SOTA. Then I saved again and when I went to the database to upload this second .csv file this is the different behaviour I noticed:
If I try to upload the second .csv file of today on the newDB, I get the following message and the file can’t be loaded:

On the other hand, if I try to upload the second file of today on the oldDB, which is something I’ve done several times in previous days with this same good result, it perfectly understands that all the QSOs have already been uploaded before but the last one, so all QSOs are ignored (grey text) and the last one (black text) is correctly included. See image below:
imagen

What the newDB did today was done exactly the same way a couple of days ago when I tried to do the same I’ve just described to you, so it’s not something that today is not working but something that has been working wrongly for some time.

PM #2:
Hi Andy,
On Dec 27th I chased my friend EA2GM/P while he was activating EA1/AT-208.
I used a web sdr to copy him and when I introduced this QSO to the newDB, I forgot writing on comments the fact that I used the web sdr for reception.
This was the QSO initially introduced:

I decided to include the missing comment about the web sdr RX and before deleting the existing QSO, I introduced an identical one with the comment about web sdr RX. This newly introduced QSO got zero (0) points because the previous one was still there and it had the 2 points for that summit. No problem so far.

The problem came when I deleted the initially introduced QSO, the one with the 2 points and without the comment about web sdr RX. Upon deletion of this initially introduced QSO, I expected that the other QSO introduced later with the comment about the web sdr RX would get the 2 points, but it didn’t. It remained showing zero (0) points.
All the above was done with the new sotadatabase.
At this point, I decided to introduce again the same QSO with the comment about web sdr RX, but this time I did it using the old database. Oh, suprise!: the QSO introduced with the old database got the 2 points, while the one introduced with the new database didn’t.
See both QSOs below:

Finally, I deleted the QSO with zero points and the one with 2 points remained correctly showing the 2 points.

Upon deletion of the initial QSO, the one without the comment about web sdr RX, the other QSO should have got the 2 points but it didn’t. It seems to me this is a bug and I write you to make you aware.

I hope this helps you solve those problems.
Good luck, Michael, with your duplicate issues.

73,

Guru

1 Like

Hi Michael

Not sure if this helps but i noticed that issue with a activator log that included a S2S.
I wanted to correct a typo and deleted the log, after the correction I re uploaded and got the duplicate error. I finally noticed that i was showing up in the chaser section and there was the S2S entry. I then deleted this chaser log and was able to re upload the activator log.

Maybe this helps, good luck with the upload
73 Sabrina HB3XTZ

Are you uploading activation logs or chaser logs?

Activator, it’s sorted now, I had to delete the entire days log from the OLD DB and upload again to the NEW DB, it randomly took this time.
.\

No it didn’t randomly take. It may appear that way but the problem will be causal. There may be a bug in the new code or it’s the way the data is presented by the user. But it will be reproducible and thus fixable. The bug, if there is one, needs to be fixed or better instructions provided for the users if there is no bug. If not, there will be continual reports of problems.

You can only activate a summit once in a day. The software only lets you upload an activation log for a summit once per day by rejecting another upload for the same summit for the same date. If you make a mistake you need to delete the old log entered for that summit and reload a new log with the extra entries. If you try to append you will find it wont work. If you are uploading with CSV/ADIF then it is easy to edit the file you previously uploaded and reload having first deleted the logged activation. If you entered the data by hand then you can download the log as a CSV file and edit that, delete what was there and reupload.

The entries need to be in date/time order for a whole host of internal reasons and to enable multiple activations etc. to be loaded in the same file. If the file contains S2S and chaser logs as well then you will find your own log will contain duplicates if you reload. The database software is aware of this and should correctly score them as zero points. Though as Guru says, there seems to be an issue with correcting the score when duplicates are deleted. That will get looked at in due course (hey it’s Christmas!). In the meantime, people should live with errors as once the bugs are fixed your own scores will be fixed when you enter more logs.

Anyway, it’s sorted for you now and the extra info in here should make things easier for you next time.

Thanks for the detailed reply, and yes, I can see your rapid response, and help.
Merry Christmas, and Happy New Year Sir! :wink:
.\ichael

1 Like

Basically this stems from the merging of the activator/chaser upload piece. I can work around it, but you may need to bear with me on finding the time to make sure it all works perfectly before I commit code to production.

Bug found and will be fixed shortly. Incidentally, humour me and try to enter duplicate S2S entries and see if both update correctly or not. A quick search of the old db code suggests that the same code for Chaser entries doesn’t exist for S2S but I didn’t look too deeply.

As Andy mentioned, you have to have your log in increasing chronological order, and you have an entry at 21:45, then follow with one at 21:25. In your original post, it’s 21:25 and 21:23 in that order. If you reorder them, it will work.

Yea, I found that out the hard way after toying with it for about an hour. :hushed:

As Andy mentioned, there’s good reasons for the restriction (mainly due to activations across UTC boundaries being counted as one or two activations), and, unusually for us, it is actually documented:

https://newsotadata.sota.org.uk/en/upload/activator/csv/info

(see common errors at the bottom)

Hi Andrew,
I’ll be pleased to try out and give you feedback on whatever fix you might get prepared.

OK, I’ll try this too and will let you know.

Cheers,

Guru

Oops! :blush: I didn’t look either. I think there is/was something… I hope it didn’t get removed by my fat fingers when not looking.

Hi Andrew @VK3ARR and Andy @MM0FMF,
I’ve just tried the duplicate entry of S2S QSOs and found the following:
Upon entering my testing S2S QSO the first time, it got the scores correctly. Then I entered the duplicate identical QSO and it got correctly zero points. No problem so far.



Now I deleted the initially entered QSO, the one with the points and the second identical QSO should get the points, but it didn’t:


At this point, I entered again the same identical QSO and it got the points, while the one which was already there from before remained at zero points.


Finally, after having run this test, I deleted the 2 false testing S2S QSOs and after confirming in both cases that I really wanted to delete that QSO, I got back to the S2S log to realize that none of the 2 false QSOs have been deleted.
They are still there and I think I’ll need some of the admins to delete them.
Editted to add the following:
After logging off and back in, I have successfully managed to delete both false testing QSOs.
73,

Guru
P.D. all of the above was done using the newdatabase.

OK, thanks. I meant test the S2S on the old database. In any case, I’ve fixed this now for both S2S and Chaser deletes.

1 Like

OK, the logic is as follows:

  • Duplicate activator entries are a fault in the file, and will be marked for correction.
  • Duplicate S2S fall under the duplicate activator entries rule
  • Duplicate Chaser entries are marked in grey and not uploaded to the server.

Please try it out now (make sure you reload newsotadata)

Hi Andrew,
I logged these SOTA chaser QSOs on F6ENO’s SAISIE SOTA program and I uploaded to the newdatabase the .CSV file this program produces upon making clic on save.

You can see here the uploaded QSOs:

After the upload, I added a new ficticious TEST QSO to my SAISIE SOTA log, You’ll see it at the bottom of the list:


I clicked on save and went to the database to upload the updated .CSV file.
When I tried to upload the new .CSV file, this is the error message I got:

My only possible option was clicking on Cancel, but I didn’t do it.
Since all the duplicates are correctly marked as such on the rightmost column and the new ficticious QSO is correctly marked as Chaser Entry on the second column from the right, I went to see my chaser log to check whether the new ficticious QSO had been loaded, but I found that it’s not there.
This is behaving exactly the same way it was in the past when I warned you about this, so it looks like the fix you may have implemented is not working or it hasn’t been properly implemented.
73,

Guru