Possible Bug in Log Entry Program

Online Resources Database
1

When I type in my activator logs, using the new database, I often do large logs with many entries. Many times there are several instances of two contacts made during the same one-minute time entry.
I always try to enter these contacts in the same order in which they were logged on the mountain.

Now with the new database, I’m seeing many instances where I enter the contacts in the correct order, and I check to be sure as soon as I enter the second contact, and then in a few minutes, the two contacts are upside-down, swapped, so that they are in reverse order! Of course they still say the correct time, but they are definitely being reversed after I have entered them.

At first I thought that these errors were my fault, but lately I’ve become more careful and watchful, and stressed out also, and I know the logging program is turning these entries upside down. There are more related issues:

  1. Not all entries with the same times are being reversed.

  2. Attempts to correct the reversal are often frustrated, as the system reverses the entries in a short time as I add more QSO’s. It also reverses other entries with the same listed times.

  3. Tonight while I corrected one pair of reversed entries, I watched in horror as another pair of entries were reversed the moment I entered the correction for the first pair!.

Clearly something is buggy about how these entries are indexed. It is almost impossible to get a large log corrected, as each correction triggers another reversal! Then going through the whole log to re-check is an exercise in madness…

Does it really matter? Only entries with the same listed time are affected…

Yes, it matters, because checking the log for accuracy is much harder with reversed entries. They appear to be omissions at first, etc.

I’ve always taken some pride in getting my logs accurate, and I spend time double-checking, and this is a new issue - I never observed this problem until we were forced off the old system.

Please reply if you have noticed this problem - it is possible that not all users will see it. If you use a logging program and upload the entire log, you may not see it - and if you don’t go fast enough to get two QSO’s in the same minute, you won’t see it either - and only some QSO’s are affected, not others, in the same log.

I have seen this problem in almost every recent activator log I have attempted to do correctly.

I offer these observations in the hope that this will be useful to others in a positive way.

73

KX0R
George

2

Hi George!

I haven’t noticed this issue, but my workflow for entering logs is quite different from yours.

What I do is enter everything in to a Google Sheet (you could also use Excel or some other spreadsheet app). This minimizes my typing as I can ‘drag down’ the values for large chunks of QSOs that are all the same. Once I’m finished entering it all in, I download it as a CSV file and then upload it to sotadata. It’s the fastest way I’ve found to do it, and if there is an error you just edit the sheet and re-download it as a CSV, then re-upload it. It’s way faster than typing the entries in one-by-on in sotadata!

I agree that the import ought to keep your log in the order in which you entered it, and I have no idea if it does. That is probably a question for Andrew @VK3ARR.

If you are interested in the method of entering logs that I described, I’d be happy to demonstrate it for you.

Thanks for all the QSO’s. It seems like we have a contact almost every day!

73,

-Josh

3

If you’re doing large logs, really use the CSV option. As Josh points out, it automates so much of the log entry anyway it’s bound to be faster and you can immediately add in S2S entries, not have to do that separately. You also have a text file record of what you uploaded too.

But, to answer your immediate question. The order of entry isn’t automatically guaranteed to be taken into consideration for sorting. I’ve got a “fix” that might work, but I can’t actually reproduce the problem, despite entering 10 entries with the same UTC date, they want to stick in the order I enter them. So, I’ll push that at some time over night and you can try again.

4

Greetings George old mate I have a trick of my own for this same thing.
If you have 2 contacts in your mountain log on the same minute enter the second callsign first in the csv file then the first and let it do its thing swaping the order. Then give it the finger.
regards
Ian vk5cz …

5

It happened all the time on the old system. The underlying database schema and queries are the same between the old retired code and the new shiny code. When the date and the time for each QSO is the same, how do you know which to put first?

I do understand that it may be annoying however.

6

I noticed that too.
But it’s no contest log so in the end the order is not relevant.

My 2cents
73 Joe

1 Like
7

OK, this is pushed now. No idea if it’ll fix the problem, still haven’t been able to reproduce (though I can understand the underlying mechanisms at play).

8

Can’t it have hh:mm:ss?
I never experience such problem because I use SAISIE SOTA program for making my log (both activator and chaser logs) and then I upload the .csv file produced by this program.
The SAISIE SOTA program offers the possibility of entering the time with a precision of seconds, so when I have 3 QSOs in the same minute, which is sometimes happening in my logs, I enter the first QSO with hh:mm:10s, the second QSO with hh:mm:30s and the third QSO with hh:mm:50s
So all 3 QSOs get 20s appart one each other and perfectly listed in the right order.
Should it be possible that the database offered the possibility of entering QSO times like hh:mm:ss, the problem would be solved.
73,

Guru

1 Like
9

3s537d

1 Like
10

I’ve checked my logs (I have only a few so not a large sample) and all contacts occurring at the same time have the calls in alphabetical order. Might be a coincidence or a clue :slight_smile:
73
Randy W2RAN

11

Coincidence. When retrieving a log that is sorted by time, you are more influenced by the order of where data is stored blocks on disk than anything else when dealing with “same time entries”.

12

I just did a test, and it looks good Andrew!!

Here is what I did…

Composed a log using Google Sheets:

V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W1QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W2QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W3QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W4QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W5QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W6QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W7QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W8QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W9QSO
V2 WU7H W7W/CW-033 11/03/2020 2240 14MHZ CW W0QSO

Downloaded it as a CSV and uploaded it to sotadata… which resulted in:

image
image2778×1124 203 KB

It kept them in the same order that I entered them. :+1:

13

Andrew,

Your fix seems to be working well - Thank you!

I did several large logs today, and I saw no reversals. Several times I had to insert calls I had missed, yet all my entries were stable. No changes were required, and there were many entries with the same listed times. I suspected that something had changed before I saw your note here!

I agree that I should do my logs on a spreadsheet and then upload them instead of typing into the interface.

The problem is that there are many ways to do this, but I lack the detailed knowledge of where to start. I read your rules about the formats required, but I have no formatted spreadsheet to start with, even though I use Excel every day.

Also I tried making corrections like I used to with the old database:

  1. Download the database CSV log with the error
  2. Save it in Excel and rename it
  3. Make the correction and change nothing else
  4. Save that file
  5. Delete the bad file from the database
  6. Upload the corrected CSV file

On the old system this worked and was easy.

On the new system, I do just what I did before, but when I upload the corrected CSV file, the system will not accept it because of format errors.

The first message said I had a problem with the header - wrong version - yet every line says V2. I tried modifications to the file, eliminating the columns on the right, etc., but no luck - I have no idea what the corrected file must look like, so I don’t know how to make a correction in the logical way that was previously possible.

I had not entered my S2S contacts yet, so this was not the problem. I make and have a lot of S2S contacts, so this is an issue going forward - doing the entry all on one sheet makes some sense, but I think we may have traded one problem for another.

I am more challenged by the logs and the database issues than by hiking and activating - even with all the snow we have to deal with. I make mistakes doing logs.

The fact that there is no system buffer for the logs, as they were previously stored progressively in partial form on the system, without being fully saved to the database, is tough to deal with. Now, if I make a single dreadful mistake on the keyboard, the log is blown away before any of it uploaded - this is truly cruel, with more than 50 entries, etc.

Please understand that some of us who can climb high and activate, and do solid, fast CW sessions, yet we are so far behind your level - and other activators - that we really need some help to learn how to enter our data in the correct format for the new system.

I would say it like this: I can climb many mountains and I have done many logs, but I need to know where the trailhead is, at least a trailhead that will work for me with my limited knowledge and old hardware. I think that I am not the only one who would like some help with things.

Thanks again for your work on the RBN Hole - the Hole worked so well today - it was like I had an automatic spotting service as I jumped from band to band.

73

George
KX0R

14

Dear George,
I feel sorry for you after reading about all the huge work you are having for uploading your logs to the database. It doesn’t make sense that you keep doing things the old way now that we have the new database and separate entering for standard and S2S QSOs is not anymore necessary.
Uploading one single file (either .csv or .adi) is now enough.
I recommend you to adopt the use of an independent program for typing your activator log in and creating your activator log file (.csv / .adi) for you to upload it to the new database.
Although there are several programs able to do this for you, I can only speak about SAISIE SOTA, by Alain F6ENO, as it’s the only one I know and use, as well as the one I have helped Alain on with some ideas he has nicely implemented and other things like the text in Spanish when that language is selected.
If you want, I could send you by Private Message on this Reflector the instructions you may need to download and install the SAISIE SOTA program, as well as how to use it or how I use it.
Others in the US may recommend you other similar logging programs, but I won’t be able to help you with other than SAISIE SOTA, as it’s the only one I know and use.
Thank you for all the QSOs and summits you’ve given me. I’d be delighted to give you something back by helping you on how to enlighten the burden of uploading your activator logs to the database.
73,

Guru
P.D, I have just sent you a Private Message (PM) through this Reflector with some help in case you want to try the SOTA logging program SAISIE SOTA by Alain F6ENO. You’ll see a green circle by the top left corner of your avatar at the top right of this page. If you clic on your avatar, you’ll see how a new small window opens where you’ll be able to find my message. Clic on it and you’ll be able to read it. Let me know, please, how things go.

2 Likes
15

Hi George,

I’m also happy to show you how I do my logging using a spreadsheet - very quick and easy. I could call you on the phone and walk you through it. Check your private messages here on the Reflector.

73,

-Josh