I’m moving soon! So, for various reasons, I am doing a whole load of painting-and-decorating to prepare to rent out my current flat. Today I was putting the final coat of enamel onto a radiator, and while doing this I was really noticing the remnants of old paint-drips that I had not quite sanded away in my preparation. Now, overall, I know the radiator will look a lot better tomorrow than it did a couple of days ago… but I still find those historic drips bothersome!
I recently purchased and installed a new boot SSD, and rather than worry about copying my installation, I decided to get Windows 7; and further; to move to 64 bit. I had actually previously purchased a 64 bit version of Vista, but been baffled by an issue with lack of support for VPN 64-bit software by Cisco, so I ended up overwriting it with a 32 bit install.
Last week, we had a heated discussion at work about encryption. We want to encrypt some data in our database, and I proposed that we go with a single private-key encryption mechanism (ignore which exact one for the moment), and my colleagues were pretty-much unanimously suggesting a ‘key per row’ approach. In this post I am going to attempt to explain the rough background, and why I felt their mechanism might not be best.
Just a little reminder note today on the simplest way to make data-model changes in SQL Server 2005 when the database is replicated via transactional replication. This is from my own personal experience of replication and very-much muddling my way through learning how to use it effectively. Otherwise, this posts presumes you are familiar with Replication Monitor and so on.
The C# code-base I work on has hundreds of places where I have felt a boolean expression could have been used to simplify the code substantially.
…or “How to improve your appalling ADSL speeds to what they told you you’d get speeds”
…or “How I split my ADSL and telephone signals and shoved them down a Cat5e cable”.
I’ve just worked on a little support problem that was quite interesting – although not in a good way – as unfortunately it demonstrates failures at so many stages of the specification and development process that I am quite disappointed to be associated with it. Associated, but not the cause of it, to be clear
Yesterday I covered the implementation details of DateTime and SmallDateTime datatypes in SQL Server 2005. I approached the issue of testing dates to see if they fell on a particular date… but then stopped-short of some fairly useful (but arcane) stuff about rounding dates.
Today I am enthused to write about the DateTime and SmallDateTime datatypes in SQL Server 2005 (and possibly this also applies to 2008, although that has additional date and time types). I am driven to write this because I have seen a number of issues relating to their use in queries and one in particular that is a real annoyance to me – even if I have to admit that it is completely and utterly pedantic (most of the time).