and a small database.
One of my tasks at work is to ensure that the installation of our software is correct. And by correct, I mean, does what I want it to do.
When I came back in January one of my first tasks was to make sure that there was an upgrade procedure to go from our old version 4.2 to our new version 4.3. Our current users (and myself) spend alot of time making customizations to the configuration of the application, creating groups, assigning rights and privileges, etc. For 4 versions now, there has been now way to upgrade the application from one version to the next so users would have to spend alot of time redoing all of the work they've spent months doing.
Today, I was trying to determine why the database upgrade wasn't working like it should. I'll leave the fact that the software is going past 8 weeks late for another day...
When the installer got to this point it would simply crash and die a horrible death. Initially I blamed it on the developers and their "It works for me" attitude. Then I thought about blaming our release manager just because its fun to make him sweat.
After alot of experimentation, as to why the script would run then fail when I started over again (by removing the database and reinstalling). It was bugging me, so I started documenting why it was working sometimes and then not.
Turns out (after saving you from some serious nerdy goodness) that its totally the fault of the implemented database. We're using a simple memory database called HSQL to store the configuration information, and well it wasn't getting the table information until after it was restarted.
I passed the information on to our installation developers and I should have a new build the end of next week. Judging from past performance and how it took 7 weeks to get a beta installation....
On other notes, I have a new word of the moment. SPORK.
No comments:
Post a Comment