The World of SQL Database Deployment

Posted by GGBlogger on Geeks with Blogs See other posts from Geeks with Blogs or by GGBlogger
Published on Sat, 17 Mar 2012 08:25:25 GMT Indexed on 2012/03/18 17:59 UTC
Read the original article Hit count: 261

Filed under:

In my early development days, I used Microsoft Access for building databases. It made things easy since I only needed to package the database with the installation package so my clients would have access to it. When we began the development of a new package in Visual Studio .NET I decided to use SQL Server Express. It was free and provided good tools - also free. I thought it was a tremendous idea until it came time to distribute our new software! What a surprise.

The nightmare

Ah, the choices! Detach the database and have the client reattach it to a newly installed – oh wait. FIRST my new client needs to download and install SQL Server Express with SQL Server Management Studio. That’s not a great thing, but it is one more nightmare step for users who may have other versions of SQL installed. Then the question became – do we detach and reattach or do we do a backup. It was too late (bad planning) to revert to Microsoft Access but we badly needed a simple way to package and distribute both the database AND sample contents.

Red Gate to the rescue

It took me a while to find an answer but I did find it in a package called SQL Packager sold by a relatively unpublicized company in England called Red Gate. They call their products “ingeniously simple” and I must agree with that description. With SQL Packager you point to the database (more in a minute) you want to distribute. A few mouse clicks and dialogs and you have an executable file that you can ship virtually anywhere and virtually any way which, when run, installs the database on your destination SQL Server instance! It really is that simple.

Easier to show than tell

Let’s explore a hypothetical case. Let’s say you have a local SQL database of customers and you have decided you want to share it with your subsidiaries or partners. Here is the underlying screen you will see on starting SQL Packager. There are a bunch of possibilities here but I’m going to keep this relatively simple. At this point I simply want to illustrate the simplicity of generating an executable to deliver your database. You will notice that you can set up a new package, edit an existing package or change a bunch of options.

Start SQL packager

clip_image001

And the following is the default dialog you get on startup.

clip_image002

In the next dialog, I’ve selected the Server and Database. I’ve also selected Windows Authentication.

clip_image003

Pressing Next causes SQL Packager to run a number of checks and produce a report.

clip_image004

Now you’re given a comprehensive list of what is going to be packaged and you’re allowed to change it if you desire.

clip_image005

I’ve never made any changes here so I can’t really make any suggestions. The just illustrates the comprehensive nature of so many Red Gate products including this one.

Clicking Next gives you still further options.

clip_image006

SQL Packager then works its magic and shows you a dialog with the results.

clip_image007

Packager then gives you a dialog of the scripts it has generated.

clip_image008

The capture above only shows 1 of 4 tabs. Finally pressing Next gives you the option to generate a .NET executable of a C# project. I’ve only generated an executable so I’m not in a position to tell you what the C# project looks like. That may be the subject of further discussions.

clip_image009

clip_image010

You can rename the package and tell SQL Packager where to save it.

I’ve skipped a lot but this will serve to illustrate the comprehensive (and ingenious) things Red Gate does. All in all, it’s a superb way to distribute populated SQL databases. Oh – we’ll save running the resulting executable for later also but believe me it’s insanely simple.

© Geeks with Blogs or respective owner