In this interview, Nathan (Nate) Suver, a senior programmer at Stratis Business Systems in the US talks about his recent experience with SQL Connect – an add-on which lets you work on databases from within Visual Studio. It also has a very similar look and feel to SQL Server Management Studio (SSMS).

Nate explains how he used SQL Connect to develop databases alongside his application code, tracked changes with his existing source control system and was left feeling pleased by the whole experience.

RM:

To start at the start, what attracts you most about SQL Connect?

NS:

I work for a small company that specializes in the line of business software for the healthcare industry. As a small development shop, each developer is responsible for delivering code that support all aspects of the application, whether it be UI enhancements, database code and schema changes, reporting and such like.

Up until this point, we would work in separate environments for UI changes (Visual Studio), and SQL Server Management Services for making database changes. From a development standpoint, this causes a number of issues.

Frequently, we’ll work on projects that contain a mix of sql code and C# code, but because we work in 2 different environments, in many cases we need to check in at least 2 seperate changesets of source code for a given task. We do continuous integration at our shop, so every checkin starts a build that verifies the integrity of the source, and runs a series of unit tests against it.

Using 2 separate development environments complicates this process, because if you check in one changeset and not the other (for example you weren’t able to check in your SQL code on time), it will likely fail a build, which can, potentially, slow down work for the entire group. Having the ability to check in both SQL and .Net changes in one changeset simplifies this process. I’ve worked at larger shops in the past where a DBA handles all the “SQL work”, and up until SQL Source Control (and SQL Connect) came along, the software management tools available to developers felt like they were centered around mid-to-large development shops. Both of these tools filled in a massive vacuum that had existed in the development environments of smaller shops.

RM:

When it comes to learning how SQL Connect works were you able to understand what you needed to do very easily?

NS:

SQL Connect has a very similar look and feel to SQL Server Management Studio (SSMS) so the interface was very natural to me, it has a minimalist feel to it, and I appreciate that. I’m interested in getting my work done, not investing time trying to learn new features. The menu-ing is laid out in such a way that everything I need is right where I need it.

RM:

What problems with working does SQL Connect solve?

NS:

Well, apart from what I’ve already spoken about, the fact that SQL Connect can work side-by-side with SQL Source Control is very important to us. Some developers really like the SSMS experience, and may not want to migrate to a tool like this but having choice is important. I like that I can use SQL Connect, but another developer can use SQL Source Control and we can work together in harmony.

RM:

Can you identify any big changes in the way you work with SQL Connect that you weren’t able to before?

NS:

Apart from the improvements that we will see in our continuous integration process, it feels natural and comfortable having all my source code available in one environment. I do like SSMS, having used it for years, and for certain tasks, it still rules the roost. But for most of the changes I make on a daily basis which can include editing schemas, modifying stored procedures and other things SQL Connect is a much better fit.

Another huge benefit SQL Connect gives us, by virtue of the fact that it uses the Visual Studio tools for doing source management, is the ability to shelve SQL changes. Between the developers, this allows for greater collaborative freedom, and allows us to review each other’s work without interrupting the build process, without the need to generate scripts. It can be a huge time saver.

RM:

Are there features from SQL Connect that you wish had been adopted by other products some time ago?

NS:

A few years ago, we experimented with Visual Studio Database Edition, but it didn’t seem to fit our development model very well. We prefer that each developer uses their own local database for development, and we spent quite a bit of time trying to get Visual Studio Database Edition to work in our environment. From my perspective, it was never very intuitive, it felt like it was built for a DBA, not a line of business programmer that has to wear many different hats. It was also painfully slow, and we ended up scrapping the project, eventually in favor of SQL Source Control.

RM:

Does SQL Connect do things fast enough to suit your purpose? How good is SQL Connect at ensuring you work smoothly?

NS:

When Nick Sutherland (at Red Gate) first contacted me about SQL Connect, it had serious performance issues, to the point where it wasn’t really usable. The schema in our development database is rather large (4000+ items), and Visual Studio frequently choked when I would attempt to make changes to the SQL Connect project. Those speed concerns have since been addressed, and the performance with the latest release has been remarkably improved.

RM:

I was reading a quote where you said that you like the simplicity SQL Connect offers. Can you expand on this for me?

NS:

I like how SQL Connect is a simple bolt-on to Visual Studio, and doesn’t cram in a lot of features I don’t need. I also like how it uses the existing “pending changes” window, unlike SQL Source Control which uses its own, and I don’t particularly like that interface. One of the requirements at our shop is that whenever you check in a changeset, you have to associate that changeset with a work item number in team foundation server. This is trivial in SQL Connect, since it’s using the tools visual studio already provides. In SQL Source Control, I have to use special syntax in my checkin comments to ensure my changeset is associated to a work item.

If I happen to misspell a changeset ID in SQL Source Control, I run the risk of not associating my work item with my changeset, which means the integration build of my change won’t be set.

If that doesn’t happen, our quality assurance department doesn’t know that my change is ready for them to review. SQL Connect makes this process foolproof, by virtue of the fact that it relies on tools that are already there, that I’m already used to. The menuing in SQL Connect makes a lot of sense. It’s really simple. Right click on your schema object and context sensitive tools are available to perform a given task. When I open a schema file for editing, buttons are drawn at the top of the window that allow me to sync the schema change directly with my local database, or save the file to disk. It’s very straightforward, and for me, it required absolutely no additional instruction or training, it was intuitive.

RM:

Are there tips you can pass on which would make the user experience of SQL Connect even better?

NS:

I can’t think of any really. It fits the bill extremely well, for my particular needs. I just want a simple, lightweight way to access my sql schemas from one place, without a ton of extra fluff.