Sorin, It’s to do with a difference between how the database works and SOTAwatch.
The summits info is held in two places on the database. One table holds the summit name, heights locations etc. and another table holds the points and bonus points for each summit. We have the facility to change the points on a summit, say it is remeasured and turns out higher, then it gets a higher score. The points table lists the score for each summit for a set of dates.
When a summit is scored, the code finds all the points values and matches the points for the date in question. There is quite a lot of code to handle the fact he data returned is not in any specific order. If a summit has been rescored 5 times, there is no guarantee the last points value returned is the latest one. Hence the code to find the correct score. SOTAwatch needs to do the same lookups to find the current score.
SOTAwatch used to have it’s own cache of data for summits but that leads to problems keeping the data in sync. So now it uses the DB for data. But we do have times when the DB is unavailable. I’m guessing that for one spot the DB failed to respond in time and the old cache was used. The next spot came and the DB responded. Although this is guessing.