Application Deployment and Other Goodies

by Paul C. Zikopoulos, IBM Canada

In Part 1 of this series, I covered the richness of the IBM Explorer and its unique features that help Microsoft .NET application developers write applications for the IBM DB2 Universal Database (DB2 UDB) product on any platform. In Part 2 , I introduced you to a set of powerful schema creation wizards that let you point-and-click your way to the creation of database objects with extra features that make this process easier than ever. In Part 3, we looked at a whole bunch of features that make the day-to-day lives of application developers easier and put .NET-based DB2 UDB information at their fingertips. In this part of this series, I want to examine an important yet sometimes overlooked topic – application deployment.

In fact, deploying your applications requires just as much foresight from a database vendor as the development integration part. No matter how great your application is, if you cannot deploy it with the same ease that you built it with, then you are going to end up with another set of problems to solve.

I round off this article with some best-practice information for DB2 UDB application deployment, and describe some of the not-so-well-known utilities and new features that make DB2 UDB application deployment on the Windows platform easier than ever!

Getting the ADO.NET data provider for DB2 UDB on your system…

Once you have your application built, you need to put the code in place that supports communications between the client and the server. In the case of .NET, that is typically a native-managed provider. Unless you are using a Type 4 JDBC driver – which really doesn’t fit into the .NET development model – you have to deploy a DB2 UDB client on your workstation (or put it in the middle tier for 3-tier architected applications) to get your application to talk to the DB2 UDB server. For this article, though, I will assume a 2-tier deployment model, which can be easily expanded to a 3-tier model.

Customers have sometimes commented on the size of the DB2 UDB clients. Before DB2 UDB Version 8.2, there were three types of DB2 UDB clients (Run-Time, Application Development, and Administration); the DB2 Run-Time Client packaged the minimum file set needed for the run-time connectivity for DB2 UDB applications. Even with the feature and file restriction efforts associated with the DB2 Run-Time Client, many customers found it too large and unsuitable for large deployments. Its size was due to the support for all the languages that DB2 UDB supports.

DB2 UDB V8.2 introduced a new repackaged and more efficient client for Windows, called the DB2 Run-Time Client Lite. This client provides all of the data application programming interfaces (CLI, ODBC, OLE DB, native .Net Data Provider, JDBC Type 2 and Type 4 drivers, SQLJ, and so on) and the network libraries required for applications that use these APIs to run. This client does not come with any tools or utilities. Because of this design restriction, its footprint has been reduced to a mere 12 MB. (The DB2 Run-Time Client is about 85 MB, by comparison.)

Unlike other DB2 clients, the DB2 Run-Time Client Lite is distributed both as a single executable (setup.exe) that can be used for installation and as a set of Windows Installer Merge Modules that can be directly embedded in an application’s Windows Installer-based setup program.

The DB2 Run-Time Client Lite is available as Windows Installer Merge Modules (.msm files) for Windows Installer-based installations, which makes it easy to redistribute the client. The language is granular (which is the key contributor to reducing its size), so you select your files according to the language support you need. These merge modules are compatible with all authoring environments and the Merge Module 2.0 Object model.

Finally, the DB2 Run-Time Client Lite has its own terms and conditions, purposely delivered in a concise format in a simple text file. These terms and conditions detail the rules around the royalty-free redistribution license that IBM grants users of this client. Quite simply, you can embed this application in your application and not worry about licensing fees since DB2 UDB license fees are controlled at the server.

You can learn more about the DB2 Run-Time Client Lite in the DB2 UDB documentation or download the code with its royalty-free redistribution license at:

For completeness, you can download maintenance for DB2 UDB servers and any DB2 client at:

Now that you know you need a DB2 Client…decide how much code you need to distributed

So, now that you know you need a DB2 UDB client to get your application to talk to your database server, you need to consider how to distribute your code. You will be happy to know that DB2 UDB comes with a number of features that make this step easier than ever.

One issue that some customers run into is the size of the DB2 UDB installation image for the client or server code that they need to distribute in their enterprises or in support of their applications. I have already talked about how the compactness of the DB2 Run-Time Client Lite addresses this problem, but what about deploying a server or a different client? Hosting a full image of a DB2 UDB product when you only intend to install a subset of it can create such issues as network latency, hosting, and downloading. Customers have asked us for a method by which they could have a DB2 UDB image that would only include the components they need.

DB2 UDB V8.2 includes a new tool called the DB2 UDB for Windows Pruning Tool (db2iprune). You can use this tool to prune down the size of an installation image. You cannot use this tool with the DB2 Run-Time Client Lite since it already represents the minimum file set that you need to install for DB2 UDB connectivity. If you are installing a DB2 UDB server, or a different client, this can come in very handy and speed up and simplify the installation process.

Essentially, the db2iprune utility can be used to remove components from an installation image, thereby reducing its size. Before this utility was available, installation programs had to host a complete image for any DB2 UDB product installation – even if they did not want certain components. For example, let’s say you are deploying a DB2 UDB Workgroup Server Edition server, but you do not require any of the data warehousing components that come free with this product. Without this utility, you would have to host the full image on your network servers. The reason for this is that DB2 UDB needed a way to ensure that no matter what components you chose to install, or not install, your selections could not break the installation process. While this safeguard method ensured the minimization of installation errors, depending on your distribution mechanism, it could result in a heavy load on your communications infrastructure (and imagine the effects over POTS – Plain Old Telephone Service).

With the db2iprune utility, you can remove components from an image and use the pruned image as the basis for distribution without concern to the impact of a selected component and its potential to break the installation process. For example, without this utility, you could not host an image that didn’t include the data warehousing feature in a DB2 UDB server installation image (even if you didn’t want to use it) because if someone ever performed an installation and selected this feature, the installation program would not be able to find it in the installation program and would throw an exception.

This all changed with db2iprune. After you prune an image using the graphical installer, pruned components will be unavailable for subsequent selection. If you use a response file installation program (I will cover that in a bit), the response file will simply skip over the pruned components that are not in the image (if they are specified) and note this anomaly in the installation log files.

You can learn more about the db2iprune utility in the DB2 UDB documentation.

Now you’ve got an image…you’re ready to distribute the code

Once you have an installation image, you are ready to distribute your DB2 UDB client or server code. As mentioned in the previous section, if you are using the DB2 Run-Time Client Lite, you can use the .msm files to install the required .DLLs and drivers and make this process completely transparent to your application.

If you choose to distribute a different client or DB2 UDB product, you can use a response file installation – often called a silent installation. This installation method is what is used to distribute DB2 UDB software in an enterprise to a large number of target destinations. Basically, a simple .TXT file (shown below) is used to identify the components that should or should not be included in the installation. No user intervention is required whatsoever, so it is a vital tool for software distribution.

Each DB2 UDB product comes with a sample response file that you can use as a starting point which is tailored for your deployment purposes. In addition to this, DB2 UDB V8.2 introduced the ability to specify that you want a response file created from the GUI-driven installation program, which makes things a lot easier: the simplicity of a GUI and the flexibility of the response file.

You can learn more about using response files to install DB2 UDB products in the DB2 UDB documentation. I will also discuss an amazing utility that is available on the Windows platform in the “READ THIS: Now for some hints and tips for DB2 UDB product distribution” section.

Latest Articles