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
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
And the following is the default dialog you get on startup.
In the next dialog, I’ve selected the Server and Database. I’ve also selected Windows Authentication.
Pressing Next causes SQL Packager to run a number of checks and produce a report.
Now you’re given a comprehensive list of what is going to be packaged and you’re allowed to change it if you desire.
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.
SQL Packager then works its magic and shows you a dialog with the results.
Packager then gives you a dialog of the scripts it has generated.
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.
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