I’ve not posted to my blog since the end of May, so after two-and-a-bit months it’s high time wrote something.
Whilst I’ve not been writing, I’ve also not been checking the comments. Due to the amount of spam, I require all comments to be approved by me before appearing on the site, so appologies to all the people who had comments stuck in moderation.
I’ve now been working in my new job for 2 months and it is generally okay. Windows, VisualStudio (2003) and Sourcesafe are all colluding to slowly drive me insane but for the time being I’m keeping the urge to take a Linux LiveCD into work at bay with healthy doses of Ruby and Debian in the evenings.
The one major cock-up I’ve made at work was a MS-SQL script to delete four rows from a table. Another, related, table had been corrupted and every row had been altered to point to the same (one) record in the first table. I had written a script to delete four faulty record and then fix the data in the associated table. Since I was deleting data I, as I make a point to always do, only used the primary key column of the table I was deleting from to ensure only the specific record which needed deleting was dropped. Unfortunately I was not aware of SQLServers ability to cascade delete record, nor was I aware that this feature was in use of the tabels in question. As a result the related table ended up with nothing in it. Whoops! We are waiting for the backup tape to be sent from Derby to Nottingham in order to restore the data to a point before the script was run. Fortunately all scripts which are run on live database servers have to be peer-reviewed, both for syntactic correctness and that they perform the task intended, before they are run so I have someone to share the blame with. I am, as the script writer, ultimately responsible for this mistake (through my own ignorance) however my colleague who reviewed the script should have been aware of the cascade delete and he did not spot the potential problem either. Nevermind.
For the past week I have also been shadowing another colleague who is left the company yesterday to learn about the systems where he was the only person with any knowledge. Last night hosting services, in their infinite wisdom, decided to move all of the servers involved in these systems from one location to an entirely different part of the country. The one thing that could possibly break everything should have now been performed the very night after the last day of the only person who knew these systems! Go go gadget forward planning.
I have a number of other things to write about, but I have to go to work early today in order to be there should the server move cause any problems. Maybe I’ll find time to write some more tonight (I wouldn’t hold your breath, though).