SQL Toolbelt 2008: Predominantly an Engineering Task

The conversion of the Red-Gate tools to be compatible with SQL Server 2008 might not seem, on first impression, the most interesting or creative project ever undertaken by the company. However, the two people most involved in the project were adamant that it was a fascinating and rewarding experience. Why? We sent the indefatigable Richard Morris to find out.

The recent launch of Red-Gate’s SQL Toolbelt 2008 marked the end of several months of effort. The small multi-disciplinary project team was given a simple brief: they were to ship quality SQL Server 2008 versions of all of the components of the SQL Toolbelt, on time.

This interview with software architect and project manager András Belokosztolszki, and Head of Development Tom Harris, focuses on the decision by Red Gate to develop the SQL Toolbelt 2008, the challenges the teams faced, and the effort that was involved in its release.


RM:
“Tom, tell me how you went about developing the tools for the SQL Toolbelt 2008?”
TH:
550-Tom.jpg “I was taken into a little room at Red Gate by Neil [Neil Davidson, Joint CEO of Red Gate Software]. In reality its our spare server room. I sat on a small stool and Neil sat on a slightly bigger stool and we argued about whether we should upgrade all our tools at the same time.

He was adamant that we were going to do SQL Server 2008 support. So the plan was simple. We would support SQL Server 2008 for all our tools. There was also a couple of peripheral things we wanted to do and that was basically it.

There was much less to argue about than there would normally between marketing and product management and the different teams involved. It was predominantly an engineering task and we would go ahead and execute it.”

RM:
“Do you think Neil’s take on it was that SQL Server 2008 was going to be a stronger product than SQL Server 2005? And the fact that Microsoft has invested a great amount of resources into SQL Server’s 2008 it was bound to encourage people to invest in this rather than the SQL Server 2005?”
TH:
“That might be the case. Obviously people will go towards better technology and skip to SQL Server 2008 rather than put money into 2005.

It was just a gut feeling that this was the right thing to do. We have a range of SQL Server tools which we package together in the SQL Toolbelt and we really wanted to be able to say to our customers that the Toolbelt was now our predominant product, you get eleven tools, it’s completely intuitive, easy to use and the price is brilliant. And it cuts out any confusion for customers.”

RM:
“Would you say that developing SQL Server 2008 was technically, or logistically, more difficult than SQL Server 2005?”
AB:
“When we had SQL Server 2005 there weren’t so many tools. There are 11 products with SQL Server 2008 and so we knew that to get all the products developed and launched at the same time say in July was going to be a much more significant task and consequently the project would take longer.”
TH:
“I think it was logistically more difficult, rather than technically more difficult, because we wanted to standardize on one version of the different libraries which went to all our products so we had the same copy of SQL Compare engine in everything.

And if we used any third party products we wanted to have version of the licensing. Because what happened in the past is that we ended up with these slight mismatches which meant that it bloated our installer; so it was bigger because it had to have all these different versions in.

This release has managed to reduce the size of our installer by around ten per cent. It’s not something that’s massively important but it’s a nice thing to achieve. It means that, when people buy our products, we know that if they find a bug in our licensing or in any other part of the release it’s going to be in all our products. So achieving uniformity was a good goal to have.”

RM:
“How does the Toolbelt save time in restoring damaged or missing data from a back-up? Can you give an example?”
AB:
550-Andras-11.jpg The main use of backups is to recover a database after data has become corrupt or unavailable. SQL Server provides a backup solution that can ensure easy and fast recovery of databases. One very nice feature of SQL Server is point in time recovery, that allows you to restore your database to a state that it was just before a problem occurred. The difficulty is to identify the point in time when the problem occurred, and consequently it is tricky to choose the backup that needs to be restored.

Another problem that is not addressed by SQL Server concerns the valid changes that were made after the restore point.

For example, a user may execute a query that deletes some product orders in a table. This mistake may not be detected immediately. Once the mistake is detected, the database administrators could restore the database, but first they need to find out when the user has deleted the product orders, and after the database has been restored, the subsequent valid orders need to be addressed. We provide a solution to assist such situations in SQL Compare and SQL Data Compare. These two products can compare two versions of a database, and now they are also able to read in databases directly from backups. This helps to see the differences between the current database and a previous snapshot  or backup of the database, or indeed, one can see the differences between two database backups.

By analyzing these differences it is much easier to pinpoint in time the backup that contained the last valid data. But the help of SQL Compare and Data Compare does not stop here. Once you know which backup file contained the last valid portion of data, you can synchronize selected differences between the database backup and the live database, i.e. you can restore individual tables, or indeed, individual rows from a backup. While care must be taken to maintain database consistency, being able to recover all your data after a problem can save a lot of time, and can in this way increase the time the database is available.”

RM:
“Has the SQL Toolbelt been successful? It must be handy for DBAs and developers to see all the tools they need in one place, for a one-off price?”
TH:
“It has been very successful. Recently we’ve changed the pricing structure so customers can buy all our products in a single installer for under $2000 (£995) or a one-off price of around $2500 (£1244) for support and upgrades. It has simplified our offering. So there’s little potential for the customer to get confused now. It came to this by thinking that our message was getting a little murky, so we took some of the individual products and created the SQL Toolbelt. Simplification has been a great success. The pricing is right and people can see that they’re buying something that has great value.”
RM:
“What difference would it had made to you if Microsoft had put SQL Server 2008 out say, 2 months early? How much pressure would that have given you to speed things up?”
AB:
“I don’t think it would have affected us that much actually because we were concentrating on supporting SQL Server 2008 and not adding the other features but in the end we had plenty of time and we are able to support all the smaller features in any case.”
TH:
” We might have had to stagger our release and might have to release one of the products first, then fill in all the smaller products. That was my original concern. That main product would go out then we’d fill in with the others but as it happened we had finished a week before Microsoft launched SQL Server 2008. It was quite tight to get them all ready.”
AB:
“At the end of the day we had SQL Toolbelt 2008 ready 2 or 3 months ago but there was a lot of testing to do finalize that everything was working ok.”
RM:
“Some developers and DBAs have been saying that they are having difficulties in some versions of 2008. That they were quite buggy in places. What difficulty did you have in the builds from Microsoft? There were also problems with trying to download SQL (CTP build) Server 2008 and attempting to install it on a machine with Visual Studio 2008 already installed.”
AB:
“Actually they were significantly better than the betas we were getting for SQL Server 2005. Yes they had bugs but on the other hand I think it was a massive help for us that we were able to get reasonably good builds from Microsoft before final release. Especially in the interim second part of the development cycle.”
TH:
“I remember that our installer broke because Microsoft had tweaked something in their installer which stopped ours from working.”
AB:
“But then it’s perfectly understandable that Microsoft has the right to develop their own tools and change them if they are not working properly. For us that means changes to something and because Microsoft’s changes are not documented there is quite a lot of work we need to support the new versions but it’s a good challenge to have.”
TH:
“One of the dangers that might happen over the next couple of weeks is that they would have changed things again which means we have to react rapidly to get things right for our customers.”
RM:
“Just how much time do you test the tools before release? What processes do they go through?”
AB:
“It is difficult to estimate the total amount of time spent on testing, primarily because quality checking is part of the whole development process. It starts with the team that works on our tools. We have a one-to-one developer tester ratio, and developers and testers sit next to each other during product development.

We use continuous integration, and this helps to pick up problems early. All of our projects have a large number of unit tests that run every night if there were changes to the source code.

For example, over twenty thousand nightly unit tests ensure that there are no regressions in SQL Compare. Some problems cannot be automatically detected, so there is a fair amount of manual testing involved in our development process.

These tests include install testing on many different platforms, as well as user interface testing. We also have many keen beta testers. These people get early access to our products, and with their help we can test our tools in environments and databases that would be difficult to reproduce locally. Finally, the project team can delay the release of a product until they are absolutely satisfied with the quality.”

RM:
“Has the SQL Server Management Studio (SSMS) got the native Intellisense in it?”
AB:
“SQL Server 2008 has Intellisense in it and though Microsoft produce it now it’s not as flexible as ours. But it’s a difficult piece of technology to get right and we’ve spent several years perfecting it to get it where it is now.”
RM:
“What difference will Intellisense in SQL Server 2008 make to the customer?”
AB:
“The intellisense in SQL Server 2008 is a good first attempt from Microsoft. It will do the basics people need for their every day work.

It is important to note though that Microsoft’s Intellisense works only with SQL Server 2008 databases, so if you have any legacy SQL Server 2000 or 2005 databases, you will not get Intellisense in SQL Server.

So people will still need to rely on third party Intellisense tools like our SQL Prompt. SQL Prompt is certainly not endangered in the short term. But even in the long term SQL Prompt will have its place. It is basically the next level of Intellisense, a level that can support complex database schemata, and a solution with plenty of customizations and tuning opportunities.”

RM:
“I know Microsoft had planned to include Intellisense in SQL Server 2005 but pulled it from a beta release before they released the database to manufacturing. Why do you think they did that given that it was first introduced as a feature of a mainstream Microsoft product in 1996, with the Visual Basic 5.0 Control Creation Edition”
AB:
“Intellisense for SQL is a difficult technology to get right. The language was certainly not designed with Intellisense in mind. For example a SELECT statement requires the user to specify a few tables and the columns of these tables. Logically, one would specify the tables first, and then, once the scope has been narrowed down, one would choose the columns of the listed tables. However, the syntax of the SELECT statement first lists the columns, and only after these columns have been specified, does the syntax require you to list the tables. Because the logical structure of queries does not follow the order of the query syntax, most people will write their queries in a non-sequential way: first specifying the column sources, i.e. the tables, views, and so forth, and then go back in their editor to specify the columns. This moving backwards and forwards is very much unlike the languages for which Intellisense was available for before, and certainly complicates Intellisense solutions.”
RM:
“SQL Server 2008 introduces a few new languages like Welsh, Tibetan and Norwegian. While these new languages map to the codepages in Windows Server 2008, in earlier operating systems such as XP they fail to do. Are there simple workarounds? Does being multi-lingual, Andras, help you as a software architect?”
AB:
“The short answer is that there are no simple workarounds. The primary use for collations is ordering and comparing textual data. SQL Server often makes use of the collation support of the underlying operating system, and many of the new collations introduced in SQL Server 2008 rely on collations in Windows Server 2008. This does mean that a database that has been created on Windows Server 2008 and restored or migrated to a server with an earlier version of the operating system will stop working. From the perspective of our tools the solution is similar to the solution we had for SQL Server 2000 and SQL Server 7, i.e. we have an extra option to ignore collation information. While this may result in some performance degradation when comparing large amounts of data, this is a solution that works.

Concerning being multi-lingual and how this affects my role as a software architect, well, there is not much to say. It certainly helps to have experience with internationalized software, however the majority of our products are available only in English. We have experimented with shipping German and Japanese versions of our tools, but it looks like our customers who speak these languages still prefer the English version.”

RM:
“How fast can you react to problems if someone finds a bug?”
TH:
“We released all of our SQL Server Tools with full support for SQL Server 2008 during July and so far no customer has found a single bug in any of the products! In the unlikely circumstance that someone did hit an issue we could react in a number of different ways. The response depends on how serious and also how widespread the problem is. For a clear showstopper, we would investigate immediately. Our aim would be to generate a reproducible scenario for the bug and then look to develop a fix. Once fixed, we would retest the issue and any surrounding functionality. We would also run any automated or overnight tests to try and ensure that no other functionality has been broken by the change. Next step, would be to send the update to any customers that have run into the problem to check that we have actually fixed their specific issue. Once we have good confidence, we would run our install tests and then make the release publicly available as part of the SQL Toolbelt.”
TH:
“If the issue is less important or specific to an individual customer we may choose to deliver what we call a ‘private release’. A ‘private release’ is similar to patch, but is delivered by our customer support team via an on demand service. The private release should still fix the individual problem, but we do not run such extensive tests around regressions or installations. Typically we can react with a private release in 1 – 2 days.

Sometimes bugs are not considered important enough to warrant fixing immediately. These are registered against the product and will be reviewed by the team. Typically such bugs get fixed during the next scheduled release of the product.”

RM:
“Would you say there’s a one killer application for business in Red Gate’s SQL Toolbelt 2008?
TH:
“The Toolbelt is a broad offering of 11 different SQL Tools. As such, I don’t think it really makes sense to talk of one of the products as being the killer application. However, some products are now the industry standard for certain tasks. SQL Compare has been around for 8 years and is widely seen as ‘the way’ of comparing and synchronizing SQL Server database schemas. Anyone performing these migrations by hand is clearly missing out big-time. SQL Prompt is another tool with a massively broad appeal. Providing good Intellisense for SQL is a very difficult problem. The popularity of the tool is testament to how well we are doing, but there is more to come in SQL Prompt 4.”
RM:
“I know everyone at Red Gate is closely involved in the business so people understand how the business works. How do you think this dual role helps in developing software? Does it help you understand the needs of other businesses that much better?”
TH:
“My view is that this has been key to the success of Red Gate so far. As the company continues to grow it is becoming much harder to keep everyone, especially newer team members engaged. We do run regular remote usability session where whole teams watch customers, or prospective customers, work with the products they are writing. This most definitely keeps everyone’s feet on the ground and can highlight problems that are obvious, but only when you’ve watched someone struggle through an area of functionality. Red Gate is trying to remain a very open and transparent company. Public displays and the intranet contain all the sales figures from the current day to day transactions all the way back to the very first piece of software sold. Product engineers are probably some of the most opinionated people at the company and they are at the heart of many involved discussions about what products we should build next, or why a particular product or feature is doing well commercially.

One aspect that I have been pushing as key is keeping product teams in touch with customers. After every major launch we try and call up people that have downloaded the new release. Typically the end user is pleased to chat, once he realizes it’s not a sales call. Again, these conversations can really help us to understand how people use our tools, but also gives us an insight into how they view Red Gate as a whole”

We have twisted the arm of the marketing department of Red-Gate to give you a special incentive to purchase the SQL Toolbelt 2008. After surprisingly little coercion, they came up with the amazing offer of a  5-title SQL Server e-Bookshelf from Apress when you purchase the Toolbelt.