When an individual makes the same mistakes repetitively, you might ask why they do so, why they don’t learn (and of course; ‘Why don’t they improve?’), and so on. When the same thing happens within a professional organisation, we need to ask why the business doesn’t learn, and why the business allows the individual to continue on that path. I think I have a couple of suggestions why this might be.
The problem: Take an integer column with a value like 123 and output it as four digits, prefixing with zero if necessary, i.e. 123 gets output as 0123. You get situations like this if, for example, you store e.g. the last four digits of a card number as an integer-type, and then try and output it. As some cards will end 0xxx this means you have to be prepared to recreate the leading zeroes when displaying the value later. Here are two approaches to solve this problem.
A couple of years back I was given a set of Dicken’s novels, and have been reading them intermittently over that time. I’ve just started reading ‘Our Mutual Friend’ – which has been harder-going than several of the other books I’ve seen so far… but there have been a couple of nice little sections which I thought I would note here.
There is an apocryphal tale that goes something like: A man has a problem with his boiler that continues for months and causes him no end of bother. Finally, an expert comes to see the boiler, and the expert taps the case a few times, tweaks a fitting… and then charges the man a large sum of money. The customer is surprised and exclaims: “But you only did 2 minutes of work!”, to which the expert replies: “You are not just paying me for my time today, but the ten yeas of experience that I have!”
My house-move is coming up soon, and after a review of my technical books, I decided that some books simply had to be re-read. “Writing Solid Code – Microsoft’s Techniques for Developing Bug-Free C Programs” by Steve Maguire fell into this category. Originally published in 1993, it was a book I had strongly positive memories about.
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.