Editorials

A Data Corrupting SQL Command

I came across this blog at SQL Sentry the other day entitled “A ‘drop column’ fix you’ll want for SQL Server 2012 / 2014”, by Aaron Bertrand.. The blog exposes a bug in SQL Server 2012/2014, that, if you drop a column in a table, under some circumstances the data becomes corrupt. I’ll let you read it on your own if you’re interested.

I wasn’t going to write on this topic, because SQL Server 2016 is nearing release, and you should have applied updates to your existing SQL Server instances, resolving the problem. You did apply the updates didn’t you? Seriously, didn’t you?

I’m frequently surprised at installations of software, still running the original release bits, without having applied any updates for long periods, even many years. I’ve never written bug free software. I don’t expect anyone else to do so either. When you get a tool as complicated as SQL Server, it’s very important to watch for updates.

Should you simply apply updates to your servers? Probably not; at least in a production situation. But, you should know what they contain, and make a plan to implement them at an appropriate point in time. What that point in time is may depend on what’s included in the update. For example, this bug only impacts people who drop columns in an existing database table. Are you going to be doing that? Then you may not have to apply the update very quickly.

More likely than not, it will take you more time to dig into all the things included in an update, and determine if or how they apply to your situation, than it would be to have a test environment to apply them soon after release, and then apply them to production once they are vetted.

Have you ever been burned by not applying updates to your software? Why not leave a war story in our comments?

Cheers,

Ben