Tee hee hee… it’s always the little things that cause the most mayhem.
- The grenade was put into the code on Friday afternoon and the pin pulled.
- Saturday morning the automatic generate summitslist.csv code ran. This writes a special version for sotamaps.
- There was a muffled bang that didn’t get noticed. I didn’t get any email saying the process had failed. It hadn’t failed, it wrote out 2 files. The fact that one was total cobblers went unnoticed.
- Sometime on Saturday sotamaps pulls in the latest map data. There was a big bang but Rob was off to Italy so he didn’t notice!
- Saturday people noticed the maps were blank and didn’t immediately panic which is good. Sometimes work is happening on the live code and it fixes itself shortly after.
- Monday is when the carnage in the data is revealed
Yes, mea culpa. I did some changes to the schema for the database after the discussion that the data should be saved in decimal not string. I had to make a few changes in the code but it looked good. Then I decided to turn international support. Now changing 1 thing at time is the best way of working. That nice Dr. Taguchi ( 田口方法 ) showed how you can change many variables and still do valid tests as long as the variables are not coupled. Well changing the database schema in 2 places struck me as dodgy so I added internal support and reverted the decimal change. Are you all still with me. I needed to revert the code changes and having learnt how to get conditional compilation working I conditional flipped out the decimal code. Job done. No, compile error. Aha, fix it for the Sotamaps data as well dumbo. At this point all I had to do was type in 2 lines of code. But no why type when you can weild ctrl-c/ctrl-v and so I copied the smmitslist code into the Sotamaps code. Compiles, runs, upload it and run away. 
The copied code put the wrong separators into the file hence Sotamaps barfing. OK, it should be fixed now. Let me know if anything else is screwy.
