Database log for some activators does not open

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 :clap: