On 1st August, James Moore, head of the team at Red Gate who brought to the world the likes of SQL Prompt, SQL Compare and SQL Source Control, and responsible for the future strategy for SQL developer tools at Red Gate, set off on a "walkabout", leaving a sizeable team to run itself, for an indefinite period. Read this blog post to find out why James has made this decision.

Over recent years, my team, and Red Gate in general, has thrived by providing simple robust tools that solve common database development problems better than any other, and fit smoothly into a user's existing workflow. I've personally talked to countless people who tell me how much time SQL Compare, for example, has saved them when migrating schema changes.

However, development practices are changing faster than ever; Agile techniques are well and truly embedded in mainstream development and evolving quickly. Cloud computing is starting to affect where we store, and how we distribute, our data. An important part of my job as manager of the team is to make sure our tools evolve in the right way; to make them as effective as possible in supporting these and many other new ways of working.

As a hot-headed developer, it could be easy to get swept up in the level of automation that's now possible in integration and deployment of software builds, with relatively modestly-sized teams handling 10K automated builds a month, and Continuous Integration and Continuous Deployment moving from a team practice towards being an integral part of enterprise-wide software delivery. Why is the world of database development less enthusiastic in participating in these trends? Surely with the right tools, Continuous Deployment for database development can be a reality?

Certain complexities, such as the likelihood that databases are shared between applications, the need for data interchange between databases, and the requirements for maintaining the integrity of the data in all its complexity during deployments, all make the rapid refactoring of databases more difficult, and so we're already working hard to make database refactoring, version control, and deployment easier and quicker.

However, I came to realize that, however much I've liaised with our existing users of our products, I don’t have enough personal experience of working in an enterprise database environment, to enable me to fully understand the exact requirements for enterprise database deployments, what the real barriers are to Continuous Deployment for databases, and whether it is even a desirable goal for many businesses.

Ultimately, though, I also believe that, despite the complications of persistence and data, the principles of refactoring, automated regression testing and so on, can be applied equally as well to database code as to application code, and to great benefit.

So this, in short, is why I am on the road. I want to visit as many organizations as I can, big and small, especially if you are pushing the barriers of database development. I need to watch, and learn how you work. I need to understand what parts of your process are automated, and what parts defy automation. If you're already trying to continuously deploy databases, perhaps even to the cloud, I'd love to visit you. If the concept is anathema, I'd be just as pleased be able to visit you and find out why.

If you could spare even just an hour, I’d be grateful to hear from you. Please email me here or comment below and I’ll be in touch shortly.

In the most recent issue of the economist’s “Technology Quarterly” there is an article about one of the oldest inventions ever – the humble cooking stove. Why was this important, but decidedly "low-tech", device being featured alongside netbooks, botnets and exafloods?

The article described a project for producing stoves for refugees in Darfur. The stoves had been developed with efficiency in mind and were "state of the art" in terms of fuel economy and the effectiveness of their smoke exhausts. When these lab-developed stoves were sent for "on site" testing, however, the results were surprising and disappointing. The first thing they discovered was that one of the local dough based staple foods – assida – required vigorous stirring during cooking. The stoves were not built for stability and so the developers were confronted with the embarrassing and humbling sight of their stoves being sent crashing to the ground as people tried to use them for their intended purpose.

This cautionary tale highlights the importance of "user focused" design, even in comparatively low tech fields. The researchers had put a great deal of effort into their stove design but, by missing a fundamental use case, had ultimately failed to create a product that catered for the intended market. How many times do we see this in software development: a great "technical solution" that falls flat on its face because it doesn't actually do the job it needs to do?

The article also describes a second project, supplying stoves to local communities in India. These stoves had long chimneys to reduce respiratory problems caused by the smoke from cooking. However, a later survey revealed that just 3% of these chimneys were still being used for their intended purpose. The other 97% had either been sold or turned into irrigation channels. So, when writing you next great piece of code, bear in mind that your application is likely to be used in ways you never even imagined!

I’m a huge fan of user focused design and over the past year, Stephen Chambers, one of Red Gate’s usability engineers, has written several articles on this topic for Simple-Talk. He discusses some novel approaches to user-focused design, including a computer-free day spent sketching designs with paper and pencils, as well as some of his frustrations with software that, like the Darfur stoves, suffers from a lack of user focus by its developers.

These articles provide a great chronicle of our experiences as a team, and it is well worth giving a few of the ideas a go. However, from personal experience, I would suggest putting on some body armour before removing all of the computers from the office!

Have a great holiday season!

James

P.S. We are always looking for new .NET authors to write for Simple Talk. If you have something to say then check out our guidelines, and drop us an email! We pay competitive rates for all articles.

Over the past few years we’ve seen a proliferation of new technologies from Microsoft. We have WPF, WWF, WCS, WCF, Silverlight, ASP.NET MVC, The entity framework, LINQ, Expression Studio, TFS, DLR, DSL… The list already appears endless, and in another two years we can probably add another half dozen technologies based around Windows 7, the much-rumored Cloud OS and the next version of .NET. As a developer, it feels like we are on a perpetual treadmill of new technologies and fads. And whilst I’m sure that some of these techniques and technologies can make our lives easier, how the hell do I tell which ones?

Let’s take WWF as an example – at the moment I understand the underlying principles of what it’s for, but how do I choose whether to leverage it during my development process? I know it’s a workflow processing system. But is it going to scale? Is it going to deal with that really nasty requirement I know is waiting for me six months down the line? I know that it will take me a week or two to roll my own solution which is sufficient, but it might take at least that long this time round to learn about WWF and decide if its going to help me or if I should roll my own. All these questions and so few answers.

How do you choose which technologies to learn? Have you spent time exploring these new possibilities? Are you still using C++ and Active X? I would love to hear what it takes for you to invest in a new technology. For me, I try and track adoption rates of these technologies; once they hit a certain % my job requires I spend some time learning about them to see if there are any opportunities there. But how do you deal with this if you have the pressure of project deadlines?

If you’re looking for simple solutions to make your development process smoother, then there are hundreds of mini-features in .NET Reflector which do just that. While working with Lutz on the transfer of the tool, I spent a lot of time digging around in its technological guts finding them. Given that some of these bits of functionality gold can be a little tricky to find, we have an article on .NET Reflector this month to make your life just that little bit easier -  Reflector: Soup to Nuts is something like our very popular SQL Server Crib sheets, so let us know what you think!

If the feature you wish Reflector had is not in the core product, then there are over 30 add-ins available on codeplex.com. These add a huge amount of functionality to Reflector, from code analysis through to small tweaks to the UI. We also asked Richard Morris to sit down with the most prolific add-in author, Jonathan De Halleux, and discuss MbUnit, Reflector and working at Microsoft on Pex. We think he deserved to be Geek of the Week, but take a look at the interview and decide for yourself.

As always we love to hear from you, so if you have any feedback on Reflector or ideas for features you would love to see added or tweaked, please let us know!

Cheers,

James.

Wow,

Lionel pointed me towards some news today announced on Scott Gutrie's blog.. Microsoft are to release the framework libraries source code with Visual Studio 2008. Seems like my usage of reflector will be going down!

A year and a little bit ago, I sat down with Tom (head of development at Red Gate) to talk about what was next on the cards after SQL Data Compare. Tom asked that I join Helen and the rest of the SQL Backup team to act as technical lead on a new version of SQL Backup; this became version 5.0 a year later (with two interim releases of SQL Backup 4 in-between), and SQL Backup 5 is now ready for consumption.

I believe the final version of SQL Backup 5 raises the bar in the backup market, bringing Red Gate's principles of ingenious tools to a market where usability and intuitiveness are oft neglected and replaced with hundreds of fairly useless and incomprehensible options, with very little guidance to help you, the user.

There are too many new and exciting features to list them all here; however I will give an overview of my favourites:

The timeline must be one of the most fundamental changes to SQL Backup 5; Dan has done an awesome job of implementing Dom and Jamie’s designs – we spent a long time on the underlying data model, making sure it scaled up across your enterprise, whether it be 5 machines or 500 machines. Helen, Jason and Priya (and the other testers we stole from different projects for varying amounts of time) have done a wonderful job testing it – often to my despair…*

In addition to the major new UI, we have been busy working on the underlying engine; Peter has done a great job of improving performance, giving us an even greater edge over our competitors, as well as adding new, often-asked-for features such as multiple thread backups creating a single file. These give the performance of backing up to multiple files the simplicity of handling just a single file.

Another important thing for us was improving the support for cluster installations, and I believe we have carried this aim through. Our installers are now cluster-aware and should install SQL Backup seamlessly to your clusters. Our cluster licensing tool, LicenseActivation.exe, will also license all nodes in your cluster for you.

The final feature that I will mention here (there are many more goodies – have a dig around and see) is the new reporting mechanism in SQL Backup 5. This will allow you to generate reports from all your installations of SQL Backup 5 across your enterprise. The reporting mechanism tells you about any backups that generated warnings, successful backups, and failed backups, all from a single location ready for you to print off.

Whether you already use SQL Backup, have done in the past, or have never tried it before, I would encourage you to give it a go – in the words of Dr Pepper: "Try it, you might like it. What’s the worst that could happen?"

Download SQL Backup 5

*Jason took it upon himself to act as timeline destroyer, throwing more and more data at it. I think the record was 5000 databases on a single instance with a million or so backups in the backup history over the period of a few days – after quite a bit of work with ANTS profiler, and some tweaking of the information queries we were running on SQL Server, SQL Backup can now deal with these situations relatively well.

***

To celebrate the launch of SQL Backup 5.0, we’ve teamed up with the newly released SQL Stumpers Volume 2 e-book to offer one SQL Backup Pro license each to three winners who answer the following backup-themed SQL Stumper correctly.

You are doing a restore to a point-in-time. You have a full database backup from 8PM and one transaction log that covers the time from 8PM to 10PM. Your server is SQL Server 2000. You accidentally put in the point-in-time of restore to 11PM. In Enterprise Manager, what will be the result?

(Contributed by Robert Marda)

Choose one of the answers below:

1. The full backup will be restored and the transaction log will be applied to 10PM.

2. The full backup will be restored, and then the database will go into suspect mode when it tries to apply the transaction log to a point-in-time beyond its scope.

3. SQL Server 2000 won’t let you put in a time that is not in one of the transaction logs.

4. Only the full backup will be restored.

If you think you know the correct answer and would like to be in for a chance to win, please send us details of which you think is the correct answer with your name and email address to editor@simple-talk.com.

Thought I better post this incase you havn't seen it -

If you are using SQL Server 2005 maintainance tasks and upgrade to sp2 be ready for a nasty suprise. If you have a Maintenance cleanup task or a history clean up task your units which used to be measured in days are now measured in hours..

See: http://blogs.msdn.com/sqlrem/archive/2007/02/24/Maintenance-Plan-Changes-in-SQL-Server-2005-SP2.aspx for more information..

- James

Its always nice as a developer when you find a new tool to make your life easier - understanding what is actually happening during the execution of your application (rather than what you think is happening) is key to fixing those hard to find bugs.

Visual Studio does a pretty good job of helping with this with its condition break points, break on thrown exceptions etc however its not always quite enough, I normally have a whole series of other tools open when debugging an application - whether its one of the sysinternals tools (dbgview, filemon, regmon, handle, and pstools among others), a copy of Ants Profiler or the SQL Server Profiler.

So its always nice when you find a new tool which makes your life even easier - I came across the managed stack explorer the other day which seems to be a great way to log how your stack changes over time - I'm not sure they have the architecture totally correct as it polls the application every x milliseconds rather than giving your a trace - personally I would rather have a trace of the stack over a period of time with the ability to explore the arguments of each call without having to step through the applicaiton - but it is certainly an interesting and potentially useful tool.