I was all set to write about how fabulous the work was going on my project until yesterday. I lost 2 1/2 weeks of data that was very tedious, involved, and complex to get into the system. To say I was upset would be putting it mildly. Once I figured out what went wrong and why I was so incredibly furious I had to leave work. Seriously, it was that or start cussing people out. And since I value my job, I took off early.
I’m using an add-on software that communicates with the primary software on the server. Well it is supposed to. Apparently, there was a domain resolution conflict between the server access and my terminal access. One side was set direct w/no need to access DNS resolution. One side was set to depend on DNS resolution. Of course, at the time I am unaware of any of this. Since I don’t control installations, it’s not really something I’d be expected to know.
After we push to production, I notice data is missing. I reload the add-on software and the work I spent so much time entering is gone. Two hours later it’s obvious the data is unrecoverable. I revert to my backup to recover the lost data. And here is where stupidity rears it’s ugly head. I load my backup and it’s basically empty. After some intensive research and more than a little frustration, I discover the flaw. Apparently, the software decided to ignore my direct saves to my backup folder and save internally to a cached file. And here is where it really gets juicy. The moment I opened my backup copy it overwrites the internal cache wiping my work. No notice, no pop up, nothing. It just overwrites the cache. To say this is a stupid bug in the software would be an understatement. I pulled up the journal entry and sure enough it just re-saved to the same file twice every day. The first save was the default save and when I used ‘save as’ and pathed out my backup folder, it just overwrote the internal cache file. Utterly stupid.
So yeah, 2 1/2 weeks of work down the tubes. And while I’m sure the bug will get fixed, that does nothing for me now. There is no ‘undo’ function and since the data never made it to the server database, it can’t be pulled back. At least this time around, I know the material better and will have to do less trial and error. I mean building calls to restricted confidential databases requires a lot of specialty message keys. I kept great notes as well so the rebuild won’t take as long but will be just as tedious. I’ve also created a sync call for the cache copies of said files to avoid this painful bug in the future.
On a good note, I was so angry I had a killer workout at the gym. lol I baked my chest and triceps to the point of almost not being able to put my shirt on afterwards.
That really sucks, but things always do go easier the 2nd time around.
As a programmer, I can only wonder how exactly this was not noticed when implementing saving. So as I understand it, when you pushed data while working, it didn’t go through to the server due to the domain resolution conflict, and you weren’t successfully backing up locally due to the caching bug? How exactly does the domain resolution problem affect local saving? Anyways, that sucks big time… I once lost 3 months worth of “work” when the machine I was working on finally gave out after being struck by lightning prior to my arrival (thanks for telling me about that, guys). It wasn’t actually that bad though, because a) the “work” I was doing was mostly to build domain knowledge for and was logistically unrelated to the project I was about to start anyways, and b) I was a research intern, so nobody cared what I was actually outputting at the time, myself included. I’m sad to hear your situation was not so amenable to sudden and irreversible loss of data. 🙁
In any case, whatever programmer is responsible for this should be garbage-collected. Dohohoho :Y