I’ve just uploaded a bug fix for the database. Actually 3 bugs and an enhancement.
OH display bug. Display info for OH summits that have a bonus finishing on 29th February would cause an exception. Now fixed.
Activation count bug. The only way to fix activation logging errors is to delete the activation log and upload the corrected version. However, a bug in the activation count code meant that when a log was deleted the count was not adjusted down. So a single activation with logging error could result in the summit’s activation count being 2. This is fixed and the activation count is now derived from the number of activations logged and should always be correct. As a side effect, any summits that have an incorrect count will correct themselves when a new activation is logged. Given the time the database will heal itself but unlike Skynet should not become self-aware and destroy mankind!
Last activator bug. Related to the above. When logging an activation, the last activator and last activation date was whoever last submitted a log for this summit irrespective of the activation date. Now fixed, the last activator will now be the person with the newest activation date. Here’s the cool bit… if you delete an activation the last activator and date are found from the activations and updated. This means activations can be added and deleted in any order and the last activator and date will be correct.
Files for download like the summitslist.csv are rebuilt by the code every 24hrs. There is a possibility that someone may try to download these files when the database is recreating them resulting in short files. Now changed so the file is deleted, then a temporary file is created and finally renamed. If you hit the update time you will either get no file found or a valid file. It should not be possible to get a short file. (This is not the Firefox 9.0.1 issue some people have seen.)
Fixing the last activation details and count was a royal pain in the bum. Involved and fiddly for only a marginal benefit but it accounted for a disproportionate number of emails in my inbox!
If you find any problems that seem related to the changes, don’t post them here but email me at mm0fmf_sota AT intermoose.com and put the word DATABASE in the subject somewhere.
Well done Mighty Database Conqueror!.. but that annoying “First Activated By” issue remains. Jimmy waits with baited breath to see whether you can fix it for him. (Psst: Ailsa Craig).
Summit Name: Ailsa Craig
Summit code: GM/SS-246
SOTA Association: Scotland
SOTA Region: Southern Scotland
Grid Reference: NX 019998
Height: 338 M / 1109 ft
Special Notes:
Extra Info: View
Scoring History
From To Score Bonus
01/Jul/2002 31/Dec/2099 1 No
First Activation
Date Activator Callsign
13/Aug/2009 MM3EYP/P
I presume what Gerald (et al) has noticed is that the SOTAwatch pages do not yet look to the new Database field to read the data for the first activator. But yes, Jimmy has been getting in my ear much less since you fixed the Database side of things Andy! (Thanks).
Ah, right, I understand. However the problem is, I suspect, that most people don’t notice the difference between the two. From what Tom said I assume that a SotaWatch web code update is also needed.
I presume what Gerald (et al) has noticed is that the SOTAwatch pages
do not yet look to the new Database field to read the data for the
first activator.
Correct in one Tom. I rarely look to the database for the first activator or who last activated a summit - 99% of the time I note this from the summit page as it is more convenient. Hopefully the two will align at some stage and you will be able to relax completely.
Non-existant. I merely ask for the activation with newest activation date. If there are several or they overlap the last one will be the newest date and last entered. It’s not worth the cost of doing another table join and sort on two fields to handle the few cases where a summit is activated more than once in a day.
The date is valid and so you gain an idea for the “perception of rarity” for the summit.
So that is why Helen shows up as “first activated by” on almost all our joint “first to activate” summits as she always logs after me (when she finally gets round to logging).
We have this problem quite a bit, around 10 cases so far.
If we delete our logs, Helen loads first then me after would that solve the problem or could you update the instances where is has happened?
Carolyn
BTW Helen is’t that bothered about it as you can imagine :o)
The “database” may well be fixed but I bet very few people actually interrogate the information on sotadata.org but look for details of who has activated a summit on this site.
Carolyn
I’ve CDO not OCD as I like things properly ordered ;o)
I’ve CDO not OCD as I like things properly ordered ;o)
I’m the same Carolyn - my birthday date follows a neat pattern and my intitials are CDE - what chance did I have!
When I build my own gear I make sure all my resistors are facing the same way and it really upsets me if any connections are made at less than 90 degrees!
Andy - thanks for your work on the database, I think it is a brave man who takes on such a task, as there will always be something to fix and always some that aren’t happy!
When my one of our more senior colleagues left us we gave him a little pressie. A mahogany base with five plastic ducks all in a row. One was about 3º of centre and a couple of mm out of line.
(Psst: Ailsa Craig).