Could someone explain why callsigns, with portable sign, do not open their logs in database? As activators, for example:DB6NL/P, ect.
And how a chaser can check, if he is in the log?
Thank you in advance!!!
73, Christos.
1 Like
Hello Christos,
Not sure if I understand correctly but I can guess what the problem is:
The user DB6NL has set their default callsign in the SSO account to DB6NL/P. This is not foreseen/recommended. Only the non-portable callsign should be set there (just like everyone else is doing).
That’s why the logs and status page are not showing on sotadata.
@VK3ARR I guess something for you Andrew? Or something to fix for the user?
(Potential reasion: A forward slash / is probable disturbing the the URL )
73 Joe
1 Like
Hi Joe!
Thank you for the respond!
Maybe it has to do with SOTAMAT, when they want to load to SOTAbase. But it doesn’t help really!
73 Chistos.
One can configure the callsign in sotamat so I am sure that is not the issue.
Talking with a SOTA friend , he told me and I checked it, can be found such an activator with SOTI.as. But the question remains: why the SOTAbase doesn’t reacts in this case?
Because the slash is treated as a path. Going forward activators will not be able to add slashes to their call sign as it fails the profile verification in SSO.
If I can be bothered, I could go back and update everyone that has it but it’s a vanishingly small number when I last looked.
2 Likes
Here the list of callsigns that have a slash in their SSO call:
HB9GKR/P
M6GYU/P
SP9AMH/QRP
HB9CAO/P
HB9HXG/P
RA9WJV/P
DL1DVE/P
DB6NL/P
OK2NMZ/P
HB0/PC5A/P
KN4MYD/AG
OK2KYK/P
F4JQV/P
OK1FDJ/P
F1ELJ/P
F/HB9FPF/P
DO4WD/P
F1IKD/P
HB9SHD/P
MW0XAD/P
2E0FNJ/P
HB9HNE/P
AB5ZA/7
DL6WZ/P
DG7AW/P
JJ1BBY/1
VK4BZ/P
DM2RG/P
IK1TNU/P
PY2GTA/P
4X6FB/P
DL3RAD/QRP
SQ9RHX/P
F4IHG/P
G0TMY/P
DA0CW/P
DL1HRM/P
DL1HZM/P
EA5GDW/P
HB9DVD/P
HB9FRK/P
LX1FP/P
OE7WMZ/P
TM8CDX/P
HB9HKJ/P
EA7FY/P
HB0/PA5MW/P
M0WJG/P
YO8DRV/P
2E0HLA/P
DL2AMT/P
DM1TX/P
F5PMR/P
G0VDZ/P
LZ1YDA/P
OE6LGF/P
HB9GZW/P
YU1WAT/P
2E0JCM/P
DO7HBL/P
JP1SCQ/1
LX/LX2AL/P
ZB2GI/P
G5NLD/P
M0XVK/P
N1WGU/P
2E0MME/P
EA3IVZ/P
EA3TO/P
EA7/EA9AI
HA6KDX/P
HA7VY/P
LA/PA5JD/P
LU1YAI/Y
OE50XFG/P
OE5STM/P
OK5EPC/P
2E0NEI/P
F/FK8IK
F4ABK/P
F4AGR/P
F4HVZ/P
F4KKT/P
F4OKC/P
HB9GZZ/P
M0LDF/P
M1NER/P
M7GET/P
OE1ENS/P
OE1MPB/P
OZ/OE7HPI
CT1IDJ/P
It’s surprising how you can forget things with constant exposure.
I thought no it can’t be that because I have a slash in mine. I had that from the start of my involvement in 2006. Then all through when I maintained the database app and then through Andrew’s first database app when we switch to SSO. I remembered getting rid when SD3 was testing.
I was thinking if it doesn’t work then how do these people use the DB, perhaps they don’t? The problem is it works if your call contains a slash if that is the account being used to login but doesn’t work for people trying to view that account. It also shown me that there are more duplicate accounts amongst that list that need cleaning up.
It will probably be worthwhile for me not notify the owners they need to fix their call. It could be changed for them but that will probably result in more work for us after the event rather that before!
2 Likes
Congrats 
We (SOTA MT) took the decision it’s easier to fix the source of the problem than spend time writing code to handle edge cases.
There are 34397 accounts on the database. We know that there quite a few which have been created and never used. We know that people when they cannot login will try to use the “forgot password” and if that doesn’t work about 15% will just create another account. The rest sensibly ask us to help.
Duplicate accounts became a big enough problem that it took me about 18months to rid the system of all the dupes. That’s because most of those accounts had QSOs in both the user’s accounts and everything needed human examination and consideration. But having cleaned up we now have the multiple account code running. You can still create duplicate accounts though some things cannot be duplicated, you will get a message on screen warning you. We regularly run checks and notify people when we find multiple accounts.
Back to the problem. There were 117 accounts where the call sign ended /P. It took under 5 mins to generate the few lines of T-SQL to remove the /P and update the call sign. This then produced a bigger problem. Approximately 50 of the 117 were accounts people created to get around the fact they could not login and get a password reset. 30 of those 50 were simple duplicates and were easily purged. 20 required me to manually shuffle QSOs between accounts so that all the user’s QSOs were logged in just 1 account and then I could purge the duplicate accounts.
It’s taken over 5 hrs of my time to clean this up. But there are measures in place to limit the problem reoccurring. The recent change to the software (SSO) that handles logging in and accounts has many more limits on what you can put in a call sign or username (no spaces, punctuation, call signs must be upper case).
So to recap,
117 accounts where the call sign ended /P have had the /P removed.
30 empty duplicate accounts have been purged
20 accounts with QSOs in multiple accounts have been merged and the dupes purged.
No QSOs / activations have been removed.
Nobody should see anything detrimental from these changes.
10 Likes