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).
A few months ago, our client had a ‘Compliance’ team visit. It was a nightmare. Worse than the general guff Marketing / Sales Departments come up with… or those nasty little changes that are all designed to improve the user experience (you know the ones; where you have to turn some design or code on its head, just because the users are apparently totally unable to understand ‘X’ or ‘Y’*). Anyway, I’m not exactly sure what we were meant to be complying to, but some of the changes were so arbitrary that we could not think of a single justification for them.