The fact is, if you include even one ClientDataSet in your application, you need to take at least one additional step in order to deploy that application to another machine. Fortunately, the step is pretty simple. You either have to deploy an additional library with your application, or you have to manually add the MidasLib unit to your project's uses clause.

To best understand this, let's create a simple application that includes a ClientDataSet, and then look at the modules that get loaded when you run it. Use the following steps:

1. Create a new project, and add a ClientDataSet to your main form.
2. Set the FileName property of the ClientDataSet to a local ClientDataSet file. For example, set it to the customer.cds file. If you installed Delphi using the default directory locations, this file can be found in c:Program FilesCommon FilesBorland SharedData. Under Kylix, this file is located in the demos/db/data directory under where Kylix is installed.
3. Set the ClientDataSet's Active property to True.
4. Run your application.
5. Select View | Debug Windows | Modules to display the Modules window. If you are running Windows, your Modules window will look similar to that shown in the following figure. 
   
   
   

If your Modules window is empty, your integrated debugger is probably disabled. Select Tools | Debugger Options, and then enable the Integrated Debugger checkbox to turn your integrated debugger back on. You will then need to recompile and run your application.

Notice the last entry in this figure, midas.dll. Midas.dll is the DLL (dynamic link library) under Windows that contains the routines that a ClientDataSet needs. These routines are required anytime you activate a ClientDataSet, whether you are using it with local files, as in this case, or any other way. For example, if you are simply using a ClientDataSet to store data temporarily in memory, it will also need access to these routines.

If you are using Kylix, the ClientDataSet relies on a shared object library named libmidas.so.1. (Actually, libmidas.so.1 is a symbolic link. In Kylix 2, this file is symbolically linked to libmidas.so.1.0.) This is shown in the following figure.

I must admit that I think the Modules window is one of the more important in the IDE (integrated development environment). This window displays all libraries that your application has loaded, including ActiveX servers (under Windows). I make a habit of checking the Modules window before I deploy an application. This way I can verify that I will deploy all libraries required by my application.

When you installed Delphi (or Kylix), the installer also installed the midas library. As a result, if you create an application that employs a ClientDataSet and run it only on your development machine, that library is already available. If you need to distribute this application you may also need to deploy this library to a location where the application can find it. Under Windows, you will likely install this library in the Windows system directory (or system32). With Kylix, you may need to install this file to the location pointed to by the LD_LIBRARY_PATH environment variable.

Deploying Applications Without the Midas Library

You may have noticed that in the preceding paragraph I was equivocal about the need to install the midas library. This is because there is a simple step that you can take that will make deployment of this library unnecessary. Specifically, if you add the MidasLib unit to your project's uses clause, your application will link all of the routines required by the ClientDataSet into your executable. As a result, the midas library will not be loaded at runtime, and therefore does not need to be deployed.

You can demonstrate this easily. Take the project you created by following the steps given earlier in this article, and add MidasLib to your project's uses clause. When you are done, your project source will look something like the following.

program Project1;

uses
  MidasLib,
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

If you now run your application again, and then display the Modules window, it will look something like this.

As you can see, the DLL midas.dll is not listed in this window, which means that it is no longer being loaded by the application. 

Why Not Always Use MidasLib

I'll bet you're wondering why you don't simply included MidasLib in the uses clause of all of your applications that use ClientDataSets. The reason is that using the MidasLib unit increases the size of your executable. Not by much, but it does increase its size. 

How much? Well, that's easy to test. Once you compile your application, you can view the Information dialog box to get some basic statistics about the compiled executable, including its overall file size. To display this dialog box, select Project | Information for Project from Delphi's main menu. For example, the following figure shows this dialog box after compiling the simple application created earlier in this article, prior to adding MidasLib to the project's uses clause.

Displaying this dialog box again after adding MidasLib to the project's uses clause and recompiling shows that the executable has grown in size, as shown here.

The difference is a little over 200 K bytes.

There is another issue that applies when you are using Delphi. If you deploy two or more applications that make use of ClientDataSets, and you install midas.dll in a shared directory, when those applications are running at the same time they will use only one copy of the DLL in memory, using less RAM overall. Again, it's not much of a savings, but it is a savings. 

Under Linux, shared libraries are not shared in memory. Each instance of the library is loaded into its own process. (They are called shared libraries because two or more applications can share the same file on disk.) As a result, this same savings in RAM is not realized when two or more Kylix applications that use ClientDataSets are running simultaneously.

My recommendation? Personally, I prefer to include MidasLib in my project's uses clause. This way I avoid potential problems associated with external DLLs, such as their being overwritten by other applications. It also makes deployment just a little bit easier.

About the Author

Cary Jensen is President of Jensen Data Systems, Inc., a Texas-based training and consulting company that won the 2002 Delphi Informant Magazine Readers Choice award for Best Training. He is the author and presenter for Delphi Developer Days (www.DelphiDeveloperDays.com), an information-packed Delphi (TM) seminar series that tours North America and Europe, and Delphi Developer Days Power Workshops, focused Delphi (TM) training. Cary is also an award-winning, best-selling co-author of eighteen books, including Building Kylix Applications (2001, Osborne/McGraw-Hill), Oracle JDeveloper (1999, Oracle Press), JBuilder Essentials (1998, Osborne/McGraw-Hill), and Delphi In Depth (1996, Osborne/McGraw-Hill). For information about onsite training and consulting you can contact Cary at cjensen@jensendatasystems.com, or visit his Web site at www.JensenDataSystems.com.

Click here for a listing of upcoming seminars, workshops, and conferences where Cary Jensen is presenting.

Breaking News: Get hands-on training with Cary Jensen. Jensen Data Systems, Inc. is proud to announce Delphi Developer Days Power Workshops, focused Delphi (TM) training. These intense, two-day workshops give you the opportunity to explore and implement a variety of Delphi techniques with Cary Jensen, one of the world's leading Delphi experts. Workshop topics include ClientDataSet, IntraWeb, and more. Due to the hands-on nature of these workshops, class size is very limited. Reserve your seat now. Click here for more information about Delphi Developer Days Power Workshops, or visit http://www.DelphiDeveloperDays.com.

Copyright ) 2002 Cary Jensen, Jensen Data Systems, Inc.
ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT CAN BE COPIED IN ANY FORM WITHOUT THE EXPRESS, WRITTEN CONSENT OF THE AUTHOR.