It’s the way it is as that is how it worked when I inherited the codebase.
For activators (the DB is much simpler for chasers) we have the concept of an activation. So we place every QSO into a big table of activator QSOs and the we have a table of activations which identify which QSOs belong to an activation and which activations belong to a user. Given that an activation is a fundamental concept, we take a few liberties with best DB practice and we store the same data in a few places. This is heavily frowned up because now you have to go to great lengths to ensure you keep all that data in sync, especially if someone edits something.
But it does have some big advatanges which is why it was done. The entries in the activations keep a tally of how many points and bonus points were achieved. When an activtion is enetered, all the points conditions are checked and if valid, the points are allocated and stored in the activation table. When we need to display activation info such as your own history or the honour roll, the code selects the activations where the user association matches and sums the points from the activation table. The alternative would be to find all the QSOs for each activation for each user, check all the valid conditions for points and then sum and display. The resulting query would be massive and noticeably slower. For chasers it’s easier because the rules for points are simple and can be done on the fly.
So this is why we have data that says I did Broughton Heights SS-128 on 26-nov-2017 and got 2pts. What it doesn’t have is the band or mode. To find those out we do some more digging but for the reasons above, it simply checks if the activations for this user contain 1 or more QSOs that match the filter. So when you select CW, it checks every activation you have and then checks if any QSOs for that activation had CW as the mode. If so, it displays the summit and the points already calculated. In my case of SS-128 yesterday, if I select 17m as a filter, it will show that activation and 2pts because I had 1 QSO on 17m. It doesn’t show the summits qualified on 17m.
You can get this data however. Given that it’s considered costly to do it for everyone, the cost for one user is acceptable. We run the DB on a shared system and we are by far the heaviest user. I don’t want to produce queries that massively impact other users on the host as that would give the hosts a reason to charge us more or ask us to reduce the load or maybe find another host. But for a single user it’s OK.
Login and select “View Results”>“My Results”>“My Activator Log”. This defaults to the last 12 months of your activations. Click the “show analysis” check box and click Show. This shows a breakdown of modes and bands for your activations. The modes and bands shown are the popular ones, needed because I wanted to fit the display on smaller screens (not everyone has huge monitors etc.) You will see a column 23c for 23cms QSOs. In that there will be either nothing, a number 1…3 or Y. Nothing means no 23cms QSOs this activation. 1…3 is the number of QSOs and Y means “qualified on this band”.
There’s pressure to add 222MHz / 1.25m from some US users and I’d like 13cms in there as I’m am QRV on that band now. The problem is screen space. I feel that the fix is likely to be an HF/50MHz table and a VHF/UHF/SHF view.
Hopefully this should help with your confusion. But if there’s anything else just ask. As I said at the start, a lot of the functionality is how it was designed. Considering the design has hardly changed in 13years and we have grown from something that was run on an laptop in someone’s home and could be backed up onto a single floppy to a system supporting thousands of users and millions of QSOs, the original designer, Gary G0HJQ, did a rather brilliant job.