Eagle-eyed users will possibly have already noticed that the SOTA database is no longer showing any * symbols for confirmed QSOs in chaser logs. This is a deliberate, albeit temporary, measure to ensure that the database continues to perform its other functions in a robust manner.
There are now around 600,000 individual QSO records within the database, a total well beyond the expectations of everybody just a few years ago. The result is that the processing is taking longer and longer for things like requests to view a complete activator or chaser log. In fact, some of the larger chaser logs are taking more than ten seconds to cross-refer each QSO to its matching activator entry, thus resulting in the time-outs that some of you may have been experiencing lately.
In the longer term the database processing will need to be re-designed to cope with ever-larger file sizes, but, as an interim measure until the task can be completed, the asterisk processing has been suspended in order to reduce processing time.
There is, as yet, no timescale for its return. There are a number of enhancements planned for the database in the longer term, but Gary does not currently have the time available to carry out the work. We will issue progress reports when we have a firmer timescale.
In the mean time, it seems appropriate to remind everybody that the asterisk is NOT required for award claims.
Perhaps when the web masters / database people have time they could look into providing a means of downloading entire activator or chaser logs in CSV format without first having to view the log as a HTML page (but leave that option available too).
For anyone like me that likes to keep our own copy of the log it would mean less time doing so and less wasted processing being carried on the server.
thanks for the info, think we can wait a bit
The asteriks was giving good way to check unconfirmed QSOs and to solve errors on one or the other side (typing errors here, copied errors there etc.). So it would be nice to see it come back.
For the past week when this feature was disabled I would conclude that the performance problems have nothing to do with this check, as it still takes just a long time to show the QSOs.
The first and quickest possible enhancement in my opinion would be to implement a time-descending order of the QSOs shown having the latest QSOs shown at top (even better would be a stop after QSOs of the last month and a way to request the next batch of QSOs so the system shouldn’t ask all QSOs EVERY time one checks the list) .
