The link to download the summitslist.csv from the sotadata site is not working correctly and it is being redirected to the main sotadata page.
This is causing any attempts to update the Database in my SOTACSV Editor to fail and leave the user without a valid list of summits.
When the link is fixed affected users of my SOTA CSV Editor will need to delete the ‘summitslist.csv’ and SOTA_REFS.MDB files from their SOTA_Logs Folder.
I will look at my code to try to make it cope better should this happen again.
There was a DNS change earlier today to do with how the software gets built and deployed. It may simply be some stale DNS issues that will fix themselves. The DNS change can be reverted but I’ll wait till Andrew is awake and active so he can look rather than me reverting something which isn’t really broken.
An updated version of my SOTA CSV Editor which appears to cope better when it gets an unexpected page / file from the site has been released.
If anyone still has a problem with getting the latest summits list then delete ‘summitslist.csv’ and SOTA_REFS.MDB files from SOTA_Logs Folder and then try again.
Yeah, well. No big deal. It took me all of 3 minutes to uninstall, download a fresh copy, and update the database. And it works fine now so I’d hardly call that extreme. YMMV
It seems that the SOTA Site admins have changed the site again and broken my SOTA CSV Editor update process once more (it worked for me a day or two ago, but not today).
There are 2 possible work arounds for this (until I change the code again) :
Option 1 is to download the file yourself and place it into your SOTA Logs Folder and then run the Database update process, however this will be required each time you want to update.
Option 2 is to edit the Windows registry and add a value that will tell the program to use the new location.
This can be done by downloading a file from my website using the special URL:
The site responds correctly with a 302 Found and the new location as per http specs. I’m assuming you’re only handling 200 and 404 status codes. We’ve all been there, done that and remember the pain and anguish as our code stopped working.
The reason for this change was we changed how the software is built and deployed to the production server. Sadly nobody had looked to see how much data was being transferred just by users downloading summitslist.csv and it was quite a bit. Before changing the deployment system it didn’t matter. Well it was quite a lot at over 120GB/month just for this one file. Sadly that blew through an included transfer budget and incurred $40 of extra charges. That figure was only going to get bigger with time and the decision to spend $500 just for 2021 and who knows how much in future on excess traffic charges or use a redirect and place the data on one of the servers where we have much more traffic bandwidth was a simple one to make.
FYI there’s a big VE7 update (first of 2 for VE7) and some minor LX, G and TK changes coming for March 1st.
since today !
