Different strokes for different folks

There are two sorts of customers I deal with, very broadly speaking. The first kind approach a problem purely from a business point of view - "we need to do our scheduling via the internet", for instance - and are either uninterested in the technical details of how I achieve this, too busy with their own work to get involved, or just assume that they've hired a professional and that whatever solution I come up with will work and be done right.

The second type of client also has a business need, but has experience and knowledge of IT systems also. They have strong ideas about how the solution they're looking for should work and the technologies that should be used.

Both sorts have their advantages (as an advisor and/or developer) and...challenges! The "hands-off" customer allows a lot of freedom and flexibility in choosing the right approach, but can sometimes have unrealistic expectations. Pretty well everything is possible these days, of course, but some features can't be delivered within a limited budget or a short timeframe.

Naturally, it's up to me to explain the opportunities and the limitations at the outset and to frame expectations correctly, but this communication costs time and effort and is absolutely crucial to the success of a project. Delivering a technically perfect solution is only half the battle; the other half is showing the client that his needs are being met and confirming the value of his investment.

The more technically-literate customer requires a different approach. You need to know your subject and be able to support every position you take, but explanations are less necessary than discussions. On the other hand, people who've dabbled in programming or the likes aren't easily impressed, and often don't realise the background work that goes into making bomb-proof data solutions. They're often (for good and solid reasons) more technically conservative, too, and don't upgrade systems or software lightly. (Case in point - I don't have a single client using an OS newer than Windows XP...released when Bill Clinton was the U.S. President, remember).

At the end of the day, though, I enjoy working with and for both types of client, and think that it would be a sad and boring job to have if every customer were the same.

SQL 2008 date and time values

I've been looking at SQL 2008 for well over a year in various guises, but between one thing and another it's only now that I'm actually doing any serious work with SQL 2008 databases. It's a chicken and egg situation, of course; you don't want to fool around with valuable customer database installations that are running perfectly well with SQL 2005 until you're completely confident with the new version, but you don't become completely comfortable with the new version until you've worked intensively with it for a while.

However, I was examining a problem involving frequent calculations on date values recently and SQL 2008 seemed like the obvious choice. Dates are painful in SQL 2005 and all earlier versions; a date and a time are always stored together even if you're only interested in the date or the time. You can ignore the other component, but you need to take care it doesn't come back and bite you when you're doing calculations: March 4 2009 is two days later than March 2 2009 but March 4 2009 01:12 is not two days later than March 2 2009 23:59, so the answer you get is very much dependent on how you frame the question.

There are ways around these problems, of course (I usually pass all date and time inputs through cleansing functions so they all save the same way), but it's all extra work for no good reason.

SQL 2008 though, among many other improvements, features separate date and time data types. This is a particular blessing, and works simply and beautifully. I'm also thrilled to at last have a debugger in the Management Studio, and working without it in SQL 2005 databases has rapidly become frustrating.

Fame at last

Let's get this started by blowing my own trumpet: an article about mailing from SSIS that I submitted to SQLServerCentral.com almost a year ago was republished last Friday and appeared at the top of the home page. It's been read over 7,000 times in the past three days and almost 20,000 times in total as I write this, and the reactions I've received have been extremely positive.

It's only now, in 2009, that you're starting to see a serious amount of information and background on Integration Services. It's been languishing in the background since the launch of SQL Server 2005, largely, as far as I can see, because the documentation was so sparse. It was easy to be an SSIS expert up to 12 months ago, but now I have to raise my game and get to grips with the enhancements to SSIS in SQL Server 2008.