Compiling/Deploying An Application
Created with Visual dBASE 7/dB2K

Last Modified: January 30, 2001
Ken Mayer, Senior SQA Engineer
dBASE, Inc.
Special Thanks go Gary White for editing and suggestions,
and Michael Rotteck for his work with InstallShield and BDE 5.01 ...

Example files available in bu03isus.exe

NOTE: This document was originally written for Visual dBASE 7.0/7.01, it has been updated for dB2K (release 1) to include information about new properties, events, etc., and any new controls since the document was first written. If a control is new it will be noted. In updating this document, the images were left "as is" unless it was felt to be absolutely necessary to change them ...

In addition, this document refers to dB2K a lot, but unless it is about a dB2K specific aspect, the text can be used for Visual dBASE 7.0 through Visual dBASE 7.5.

Special dB2K Note: If you are working with dB2K, there is a document on working with Inno Setup that was written specifically for dB2K. It is on your dB2K CD, in the INNO folder. This covers deploying the application, you may want to read the parts of this document that discuss building the executable and preparing it for deployment.

Any developer who needs to finish their application is going to run into the fact that the process of Compiling and/or Deploying their application is not well documented in the manuals or online help (although this process is better documented in dB2K than in previous versions).

This process is actually pretty simple, but it does not appear that way the first time you try it.

You are best off using the Project Manager to set everything up -- it may take a bit of work, but in the long run, you are ensured that everything is set the way it should be.

The instructions in this document are based on a simple application, with local tables. There are more detailed things that can be done (and should be if you are working with non-local tables), and the places to handle these are pointed out, but not detailed here.

Following along, you should be able, when done, to create a project file, build/compile your application, and use InstallShield Express to create your deployment disks. Note: for dB2K developers, please see the paper noted above on using Inno Setup to create your deployment ...

Special Sections:

Some Definitions
The following phrases can be a bit confusing to some folk, so I thought I would attempt to explain them:

Add to Project File -- this phrase refers to adding any file you wish to, to your project file. In the case of any files that can be "compiled" by dBASE (creating a file with a .CO, .PRO, .WFO ... anything ending with "O" except for an Icon (.ICO) in the file extension), these files will automatically be included in the target executable (see below). Anything else, if you really must include it in the executable (some developers store empty tables or image files in the .exe and copy them out later), you must do so explicitly (see below).

Include in Target Executable -- this phrase refers to including a file explicitly in the executable. As noted above, it is possible to have the compiler in dBASE store an image file, or a table (or anything else) in the .EXE. The only real advantage to this is that if the user deletes a file needed by your application, you can have them execute some command that extracts the file, or have the application do it automatically (there is a variation on the COPY FILE command that can be used, we're not going to get into it here).

Deploy With Application -- this phrase simply means that you want InstallShield Express to deploy that file with the executable file and the tables you need deployed. This might include files like the .INI file, a BDE configuration file (.CFG), tables (and their .MDX and/or .DBT or other associated files), image files, icon files, and so on ...

BDE Settings

Unfortunately, setting up a deployment for the BDE is not as easy as one might hope.

First, if you are deploying an application that uses a BDE alias, you have to go through all the steps shown under the BDE part of the InstallShield Express setup below.

Second, if you deploy local tables to a directory other than the one your application is installed to, you must go through some steps in the GROUPS section below (in the InstallShield Express setup below -- Specify Components and Files).

Third, if you are using VdBASE 7 level tables, you should set the registry setting for TABLE CREATE (particularly if your application creates tables or issues ALTER TABLE commands, or even does a "COPY TABLE"). (This is covered toward the end of the InstallShield Express part of this document ...)

Finally, and this is the part we're going to discuss here, you may need to set up the default language driver for your application, and while you can do it in the registry settings (covered as above), you can also do it in a slightly less complex fashion:

NOTE: Check the section that covers InstallShield -- it discusses ensuring all the correct BDE files are deployed. dB2K Users, the Inno Setup paper mentioned above covers this -- it's actually easier in Inno Setup ...

.INI Files

There are often a few settings saved into the .INI file for dB2K that most people don't even think about. This may include things like the SET CENTURY setting, which will affect the display of date fields (if set to ON you will see all four digits of the year, if set to OFF, you will see only two digits ...).

If you expect your deployed application to perform in the same manner as when you were developing it, you MUST deploy a .INI file. It needs to be the same name as the .EXE -- otherwise your application will not automatically read these settings (i.e., MYEXEC.EXE would require a .INI named MYEXEC.INI).

Some settings you should consider (see online help in dB2K for details for SET EPOCH, SET CENTURY, SET LDCHECK, etc.) adding as an example below:






The "LDRIVER=WINDOWS" setting ensures that no matter what your application's BDE Driver your source code will be saved as ANSI. (There is a problem with this setting and the SoundEx() function -- otherwise this setting will enhance the speed of text processing immensely).

The "TALK" setting is very important (this is from Gary White who discovered it during one deploy he did) -- if Talk is not set OFF (either here or in your code), there will be a serious performance degradation, as Visual dBASE will go through the motions of echoing comands to the command window.

The "CommandWindow" settings are there just to be sure there are no other problems -- Gary discovered his application was going unstable without that (probably related to the TALK settings).

The "ComponentTypes" section may cause some datatype mismatch errors if not included, particularly if you are using the grid component on your forms. You should copy the section shown above from your own VDB.INI, as you may have different settings than those shown above.

The "IDAPI" section is based on the previous part of this document -- if you are not deploying your own custom .CFG file for the BDE, do not put that into your .INI file! dB2K users -- note that you may not need to deploy a custom .CFG file, see details in Inno Setup paper ...

Encrypted Tables
If you are working with encrypted tables (using the dBASE PROTECT command to do so), you will need to deploy the DBSYSTEM.DB file, but you also need to have an entry in your .INI that looks like:


Where "D:\PATH" is the path to the directory where you are deploying this file to. If you already have a "[CommandSettings]" section (see above), just add the "DBSYSTEM" entry. If you are deploying the DBSYSTEM file to the same as your application you can set this to "." (i.e., DBSYSTEM=. ) -- the "." stands for "current directory" ...

Creating a Project

If you have not already created a project for your application, you should do the following (and you may want to read the following to be sure you have done all that is needed ...):

NOTE: you will see, when you right click on files in the pane, a couple of options:

"Exclude from Build" -- only use this if you don't need a specific program, form, or whatever to be a part of the .exe. (Example: I have a program I use called SETUP.PRG - this is used to ensure that when I am coding that various .CCs and procedure files are available -- but I don't need it to be compiled into the .EXE, as the statements involved are called in my startup program ...)

"Include in Target Executable" -- this is deceptive -- it looks like you need to actually select each item to be included -- however, if a program, form, report, or other compileable file (datamodules, sql files, custom controls/ forms, etc.) is in the list, the .??O or .?O file will be automatically included in the .EXE file, and you do not have to do anything. The only reason for using this is if you wish to include tables, .DLLs, images ... in your .EXE (a trick some developers use to hide tables from the user ... we won't get into that here).

Preparing the Application

You are now nearly ready to compile your application, but there are some options you should be aware of.

Right click in the project manager's left pane, and select:
Project Properties

You will see a dialog with three tabs:


Compile Build

Compile The Application

Once you have done any settings in the project manager that are needed, you can build your application from the main menu of dB2K -- but the project manager needs to be up -- you cannot do the following without it ... (well, you can type "BUILD something" [see online help] in the command window, but it won't make sure all files necessary for the application are included in the .EXE):

Select the "Build" menu, select the menu item: "Build myapp.exe" (where "myapp.exe" is the name of your application)

Note that from the same menu you can execute the .EXE file, which can be useful for testing, and you can debug it from the menu as well ...

There are actually two steps here -- the first compiles the individual files to their "pcode" (the .WFO, .PRO, etc.). A dialog will show that this process is complete, and you must click "OK" to continue to the actual creation of the .EXE. The amount of time it takes to generate the .EXE will vary based on how complex it is -- have some patience here ... That's all there is to compiling your application (deceptively simple, eh?) ...

If you set up a log file (see above, under "Preparing the Application"), any errors (or warnings) should appear in the log file.

NOTE: If you have paths to custom controls, header files, and so on (such as: C:\PROGRAM FILES\dBASE\DB2K 01\CLASSES\SEEKER.CC ), the path is removed from the compiled version. PROBLEM: if you do not include the custom controls in your list of files in the Project, they will not be in the executable, and when you run the executable, errors will occur.


Unless your code is perfect the first time out, you'll probably need to rebuild the .EXE multiple times -- suggest that you run the "Rebuild All" menu option rather than running the "Build myapp.exe" option -- this will ensure that all programs, forms, reports, etc., get recompiled before building your executable, and then the .EXE will be rebuilt.

Deploying The Application (Using InstallShield Express)

For dB2K Users -- again, you may wish to use Inno Setup, if so, check the INNO folder on your CD for a file called Inno.htm -- this has the instructions for deploying a dB2K application using Inno Setup.

This is where things can be confusing -- InstallShield's help isn't as helpful as it could be (at least not until you've used InstallShield more than once), so here is a step-by-step walk through the different options based on a couple of installations I've created.

Unless you are very sure of yourself, you should use InstallShield Express for this, as there are registry settings (besides the ones mentioned later in this document) that are set automatically by InstallShield Express, as well as the fact that ISE handles many other things automatically. Deploying an application is not as simple as copying the .EXE and tables to someone else's computer (and hasn't been since the DOS days) ...

Select the "Build" menu, and "Create Install Program ..." (at the bottom of the menu). (You can also go straight to InstallShield Express from the "Start" menu in Win 95, 98 or NT 4 ...) If you have not installed InstallShield Express, then this will not work, obviously ...

You will see InstallShield Express come up -- this is a version created for Visual dBASE 7 in cooperation with Borland/Inprise/dBASE, Inc.. It handles things very nicely once you get used to it.

NOTE: If you have Visual dBASE 7.01, you should make sure you have InstallShield Express for Visual dBASE 7, version 2.01 (or later if they give us a new version -- this is wishful thinking on my part, not any implicit promise from InstallShield). To find the version number simply bring up the Help | About dialog ...

When you first bring up InstallShield Express, it assumes you're doing a new install, which is correct. After you've done one, the dialog will change a bit, but should be pretty obvious. Click the 'Ok' button, and move on.

Your best bet is to start at the top of the checklist provided (this is the "working screen" in InstallShield Express), and work your way down. You can click on the text or the little arrow buttons on the left of the text to get an option to come up.

The screen itself is a checklist, which brings up dialogs to actually set the various parts of the Install when you click on individual checkboxes. A discussion (with varying amounts of detail) follows for each section:

Set the Visual Design

When done, click the "OK" button. At this point, the items in this heading are all checked.

Specify InstallShield Objects for Visual dBASE

Specify Components and Files

Click 'OK', and again you should see these options checked on the yellow checklist.

BDE Installation Failures

Note that there are several different parts to what is shown here, so if one solution does not fix your problem, try reading on ...

NOTE: The following has not been tested by the author, but was posted in the newsgroups by Rick Miller (12/30/1999). This is one possible solution to BDE installation errors ("BDEEngine Error", "Merging configuration files failed", "Language Driver not found" ...). The idea is to make sure that the deployer knows to grab all of the correct files, which means doing it manually.

The following is a listing of files that need to be in the groups shown (in the square brackets) with the dates listed for Visual dBASE 7.01 (and BDE 4.5). You can set these by using the same information as shown above (for placing specific files in specific 'groups') ... The information on the BDE 5.01 was provided by Gerald Lightsey.

NOTE: See the section at the end of this document on working with BDE 5.01 ... it has provided some extra challenges for users of Visual dBASE 7.01 and InstallShield, but a few folk have successfully worked out these problems, and details are given there.

[Runtime Files] Visual dBASE files
CTL3D32.DLL 07-13-95
VDB70009.DLL 03-11-98
VDB7RUN.EXE 03-11-98
[BDE/IDAPI] BDE 4.5 BDE 5.01
BDEADMIN.EXE 11-14-97 10/10/98
BDEADMIN.HLP 11-14-97 06/09/98
BLW32.DLL 11-06-97 10/10/98
IDAPI32.DLL 11-14-97 10/10/98
IDAPINST.DLL 02-21-96 11/14/97
IDASCI32.DLL 11-14-97 10/10/98
IDBAT32.DLL 11-14-97 10/10/98
IDDA3532.DLL 11-14-97 10/10/98
IDDA032.DLL 11-14-97 10/10/98
IDDBAS32.DLL 11-14-97 10/10/98
IDDR32.DLL 11-14-97 10/10/98
IDODBC32.DLL 11-14-97 10/10/98
IDPDX32.DLL 11-14-97 10/10/98
IDQBE32.DLL 11-14-97 10/10/98
IDR20009.DLL 11-14-97 10/10/98
IDSQL32.DLL 11-14-97 10/10/98
BDEADMIN.CNT none 06/09/98
CEEUROPE.BLL 11-06-97 11-06-97
CHARSET.BLL 11-06-97 11-06-97
EUROPE.BLL 11-06-97 11-06-97
FAREAST.BLL 11-06-97 11-06-97
JAPAN.BLL 11-06-97 11-06-97
OTHER.BLL 11-06-97 11-06-97
USA.BLL 11-06-97 11-06-97
IDAPI32.CNF 02-24-97* 11-14-97

* Note that my copy of this file is dated 02/04/96 and it has worked fine for my deployment ... I am not sure why Rick gave this date ...

In addition, Rick points out the following if an installation fails due to BDE errors. This correction is based on the Corel Suite (WordPerfect, etc.), or some Lotus Products. He states that in the worst case scenario to date, they had a "corrupt Corel Database engine" (Corel uses the BDE ...). The solution that was used was the following:

  1. Uninstall the application and Corel Suite
  2. Re-start the computer
  3. Delete the registry keys (REGEDIT) for:
    Local Machine/Software/Borland/BLW32
    Local Machine/Software/Borland/BDE
    Local Machine/Software/Corel
  4. Re-start the computer
  5. Delete all Corel Application Files
  6. Delete all BDE files
  7. Install the Application
  8. Install the Corel Suite

To date, this solved the problem ...

"Merging the configuraton file has failed" error
This information is based on a technical document at the InstallShield support website (see below) -- the article is Q100670.

This message may be displayed due to one of several reasons:

Note: There are a variety of documents at the InstallShield website that deal with BDE and other installation issues that may be useful -- if the information you need is not here, try going to this site:

(This information provided by David Love -- thanks!)

Need a new IDAPINST.DLL for BDE 5.0/5.01
In addition to the information given above, a discussion from the Visual dBASE 7 newsgroups including Stefan from InstallShield revealed the following:

The IDAPINST.DLL file that ships with InstallShield Express 2.01 cannot handle the BDE 5.0 and later versions (5.01, 5.02).

There is a new dll at this website:

When you download this, unzip it, rename the version in your "IS Express for Visual dBASE\redist" directory to "idapinst45.dll" (so you still have it).

Copy the new version (idapinst50.dll) over to that folder and rename it to idapinst.dll.

When you deploy the application this will resolve a lot of problems.

"Merging the configuraton file has failed" error
According to Stefan at InstallShield, this error commonly occurs if there was a previous BDE installation and the following two registry keys still exist:


If these two keys exist in the registry, try deleting them and re-run the installation.

One Other Solution If Nothing Else Works ...
According to Steven Choi, the only solution that has worked for him is to create the installation using the BDE 4.5 that ships with Visual dBASE 7, and then use the BDE 5.01 upgrade set on the client's machine after installing your application (with BDE 4.5). This upgrade set is the downloadable stuff from the website ...

Still No Fix?
Unfortunately these are the only solutions I am aware of to date. If none of these solve your particular situation, please post the exact details in the Visual dBASE newsgroups, and hopefully someone will be able to help ...

If you find a solution to a problem that is not mentioned here, it would help the whole of the dBASE community if you would share it -- drop me an email and I will try to incorporate it into here at the earliest possible opportunity.

Select User Interface Components

Make Registry Changes

You can specify Registry keys and values here. This may be useful for your application, but most people don't need to do much with these. To use them in your application you should understand how to use the registry properly, including from within your application (see REGISTRY.PRG for API calls that can be used inside VdBASE ...). Also note that setting registry keys you usually want to allow these to be removed if the user uninstalls your application -- there is a checkbox for this which defaults to being checked.

NOTE: After some work tinkering and trying things, it may not be necessary to do all of the settings below, except for the "Table Level" -- especially if your code uses local SQL commands to CREATE TABLE, COPY TABLE, ALTER TABLE, and those tables need Visual dBASE level 7 table settings (Referential Integrity, Autoincrement fields, etc.). The Language Driver can be set from the BDE Administrator and such as described at the beginning of this document.

BDE Registry Settings
Registry changes can be tricky, but after some tinkering, the following keys values can be set in the registry via InstallShield that may be very important for the BDE. I am attempting to put excruciating detail here (NOTE: the "Value Data" for registry values -- if quotes are shown, enter the quotes -- if they are NOT shown, do not enter them!).

Click the "Add Value" button

Where "nameofdriver" is equal to whatever is currently in your own registry (you will need to run REGEDIT to see this). Example -- Western European ANSI is: "DBWINWE0" (that's a zero)

(See notes above -- this may be the only setting you really have to be concerned with)


Click the "OK" button to go back to the checklist.

Specify Folders and Icons

Run Disk Builder

Disk Builder -- as it says -- this will actually create your disk images for you. You can select a variety of disk options, including CD image ...

Note that this will create directories under your application directory ...

Test the Installation

Will actually run an installation so you can see it happen. (When done, you may want to go uninstall, or you will have the application in a full install on your machine -- this may be useful, but ...)

Copy Distribution Media

Like it says -- it will prompt for disks, etc.

NOTE: If you are working on a Win 95 or Win 98 computer, this option appears to work fine. I have seen reports, however, of users who were using NT 4.0 and either the operation hung up and stopped working on disk 1, or it took 25 minutes to complete (which is silly).

You can always use the Windows Explorer to copy the contents of the disk images to floppies ... (or even the DOS COPY command)

OCX and DLL Controls

OCX and some DLL Controls require some registry settings. The problem is that it's not 100% automatic in most cases. Below are two ways of dealing with these -- let InstallShield do it, or code it yourself.

Letting InstallShield Handle It
InstallShield Express will automatically register any file that contains the "OLESelfRegister" string in it's version resource. You can check for this by using the Borland Resource Workshop or Microsoft's Visual C++, looking for:

VALUE "OLESelfRegister", ""

If creating your own, you can add this. See the online help for InstallShield for exact details ("Self registering ...").

You can also add this section to the SWDEPEND.INI file that is created for your InstallShield Express setup


Change the "DLLNAME.DLL" to the name of your .DLL or .OCX. If this section already exists, you should add the "Register ..." statement.

You should also check the .OCX file's documentation for any dependencies that it may have. Any .DLL files that are needed for your .OCX to execute properly need to be registered before the .OCX is, so check the order in this .INI file. In addition, these .DLL files must be added to a file group in your Express setup (see above -- Groups and Files dialog) before the .OCX file is, as they will be registered on the target computer in the order they are added to the group!

Manually Handling These In Your Own Code
In addition to the above, you may want to just do this yourself.

An example of this is in VESPER7 (found at the author's web site and mirrored to some other web sites out there). This is free-ware sample code.

The basics of this are covered here.

Visual dBASE 7 ships with some registry API calls found in these files -- WINREG.H and REGISTRY.PRG. (WINREG.H is in the INCLUDE directory that ships with Visual dBASE, and REGISTRY.PRG is in the SAMPLES directory ... don't ask me why they were placed in these different directories, but ...)

The file "winreg.h" contains definitions, and "registry.prg" contains actual extern calls to code.

The fun part is that you need to check to see if the registry key is set. In the startup program for VESPER7, the following is contained in the Open method (for a calendar control created in Delphi 3 and converted to an OCX file):

      // necessary for Registry stuff:
      #include <winreg.h>
      set procedure to registry additive

      // Check to see if the Calendar has been registered
      // and if not, register it
      oReg = new Registry( HKEY_CLASSES_ROOT, ;
                           "CalendarXControl.CalendarX" )
      // if key referred to by "oReg" does was just
      // created, then we need to register the control:
      if ( oReg.newlyCreated )
         run( "regsvr32 /s calendar.ocx", false )

      // check to see if the registry key is empty -- if
      // so, something didn't work ...:
      if empty( oReg.queryValue( "" ) )
         msgbox( "Registry setting for Calendar control not set --"+;
                 "Do not try running calendar -- an error will "+;
                 "occur and may cause the program to crash. Contact "+;
                 "Ken to get a fix ...", ;
                 "Didn't work!" )

If the registry key is empty, it was probably created when we checked to see (oReg.newlyCreated) if it existed. The registry API calls being used will create the key when checking for it. If it didn't exist (i.e., oReg.newlyCreated actually returns a logical value -- true means we just created it), then we run a DOS program (odd, but true) -- the /s parameter simply runs the program in "silent" mode -- no dialog box will appear -- that will register the ocx ( "regsvr32.exe" -- note -- this program normally resides in your \WINDOWS\SYSTEM directory -- if it doesn't, or if your DOS path does not include that directory, this will not execute). (Note: there is now a DeleteKey() method in the REGISTRY object -- this didn't used to be there -- at the time Vesper was actively being worked on Visual dBASE 7.0 was the latest version -- this was added for 7.01 ... you could delete a registry key if it was empty ...)

The last thing we do is check to see if the key is still empty, and if it is, we display an error. This error is usually because the program doesn't exist (not likely, but it is possible -- "regsvr32.exe" is installed with Windows 95, 98 and NT); or more likely is the fact that your DOS path does not include the \WINDOWS\SYSTEM directory, which is where this program is installed to. You can get the user to step out to DOS and type:

     regsvr32 myocx.ocx

and it should display a (windows) alert dialog stating that it worked. (The /s flag in the RUN() call above simply runs this in "silent" mode -- so that when the start program executes, the user never has to even be concerned with the details ...)

NOTE: Using REGSVR32.EXE you can actually remove an OCX's (or probably even a .DLL's) entries in the registry by using the /U flag (uninstall).

As noted in the InstallShield part of this discussion, if your .OCX has dependencies on other .DLLs, you need to install them first -- otherwise the .OCX won't install properly.

Network Deployment

This information comes from Gary White, who has performed a network installation. The author of this HOW TO does not currently have a way to test this. If you have suggestions for network deployment that are different from Gary's, please feel free to say something in the Visual dBASE newsgroups ...

"Network deployment is a two step process. You must install the program and you must install the data files. I have not found a way to do this with a single InstallShield deployment. I build one deployment that does not include any shared tables. The tables that will reside on a shared network drive are a separate InstallShield project. The data files project may, or may not include setting up the BDE alias. The start-up program checks for the existence of the BDE alias, if it is not found, allows the user to locate the files. Once the files are found, the program creates the alias on the users' machine. A simplified version of the code for that would look something like the following, although a more complete version would check for the existence of all the files necessary."

   //Code as provided by Gary White, some of it is
   // based on code by Romain Strieff and Jim Sare
   if not databaseFound( "yourDatabaseName" )
      cPath = getDirectory()
      CreateAlias( "yourDatabaseName", cPath )

   function dataBaseFound( cDatabase )
      local d, dbArray 
      d = new database()
      dbArray = d.getSchema( "Databases" )
      release object d
   return dbArray.scan( cDatabase ) > 0

  function CreateAlias(cAliasName,cPath)
     //Creates a DBF Alias

     if type("DbiAddAlias") # "FP"
        extern cint DbiAddAlias(;
               clogical) idapi32
  return DbiAddAlias(null,;
                     DBCSToSBCSZ("PATH:" + cPath),;

   // necessary for above
   Function DBCSToSBCSZ(c)
      LOCAL cTemp, x

      cTemp = Replicate(Chr(0), ((Len(c) + 1) / 2) + ;
                                ((Len(c) + 1) % 2))
      For x = 1 To Len(c)
         cTemp.SetByte(x - 1, Asc(SubStr(c, x)))

   RETURN cTemp

BDE 5.01 Deployment

The following is based on work done by Michael Rotteck, who has done quite a bit of testing and work with deploying the 5.01 version of the BDE.

For all of this to work properly, you need the InstallShield Express update to version 2.01 as noted elsewhere in this document. This is available from the dBASE, inc. website.

Next you need the file bu03isus.exe -- this file is now included with the DEPLOY7 document. This file is a self-extracting zip file, which will unzip files needed for a US deployment. Extract these files to a temporary folder.

See notes below if you are not using a US version of the BDE. You may want to backup the files you are over-writing with new ones -- see below.

If using Visual dBASE Professional

  1. Copy the files IDAPIINST.DLL and IDAPI.CNF to the
    Visual dBASE\InstallShield\redist folder
  2. Copy the file SWDEPEND.INI into the
    Visual dBASE\InstallShield folder

If using Visual dBASE Client/Server

  1. Copy all .CNF files and IDAPIINST.DLL to the
    InstallShield\IS Express for Visual dBASE\redist folder
  2. Copy the files SWDEPEND.INI and ISDEPEND.INI into the
    InstallShield\IS Express for Visual dBASE folder

Note that with the BDE 5.01 update you get new SQL links for Oracle 8 and Informix 9.

>From this point on, you should be able to deploy a new application with BDE 5.01 with no problems, see the rest of this document for the other details on deploying the BDE.

Already Created Setup for BDE 4.5, Need to Modify for BDE 5.01
Michael suggests that to do this, you modify your installation (this should be a one-time-only operation) in the following manner:

  1. Open the setup project
  2. Go to the IS menu "Specify InstallShield Objects for Visual dBASE" and deactivate the BDE Install.
  3. Create the disk set (don't copy to floppy or CD yet ...)

This will have created a setup without the BDE.

  1. Go to the IS menu "Specify InstallShield Objects for Visual dBASE" and re-activate the BDE Install (and follow the other settings as outlined elsewhere in this document).
  2. Create the disk set

This should force InstallShield to re-evaluate the .CNF files and other files necessary to deploy the BDE, and you should now be able to deploy the BDE 5.01 version.

Non-US Versions of BDE 5.01
First off, get the Non-US version of BDE 5.01 from the appropriate Borland office (i.e., Borland Germany, Borland Italy, etc.), and install it.

Next, if you do not do the following, you will get an error message stating "VDB70009.DLL not found". This is a US .DLL file, and you need to substitute the reference for InstallShield, so it installs the appropriate language version. The following steps should solve this problem.

Open the file SWDEPEND.INI in any text editor, and make the changes noted below:

  1. In the section [VdBase Support] you will see the entry:


    Change this to read:


    You will find in the Visual dBASE\BIN folder a file with a similar name, but the last two digits before the extension (before .DLL) will be different, based on your language. Change the 'xx' in the statement above to the appropriate .DLL name ... You can also use the following chart:

    09 English/US
    07 DE /German
    0A ES /Spanish
    0C FR /French
    10 IT /Italian
    11 JA /Japanese

    Note that the "0A" and "0C" options use the number zero not the letter "O".

  2. In the section [BDE Support] you will see the entry:


    Change this to use the appropriate .DLL found in your BDE folder -- the file will be named "IDR2nnnn.DLL" -- change the reference above to match this.

  3. In the section [BDE Core Subset] you will see the entry:


    Change this to use the appropriate .DLL found in your BDE folder -- the file will be named "IDR2nnnn.DLL" -- change the reference above to match this.

Save the file, and exit the editor. When you go to create your install disk sets, you should now be able to deploy your language-specific version of the BDE 5.01.

That's it

Well, parts of this could be covered in more depth, but the idea was to give you a basic grounding in using the Compiler and Deployer options with Visual dBASE 7/dB2K. If you need more, check online help for both Visual dBASE/dB2K (project manager, BUILD ...); and InstallShield Express. In addition, you are encouraged to visit the dBASE newsgroups (see for details) to obtain assistance. Among other things, InstallShield has a person who checks the newsgroups periodically and attempts to answer questions.

Don't forget that the Knowledgebase is full of other useful documents as well as this one ...

DISCLAIMER: the author is an employee of dBASE, Inc., but has written this on his own time. If you have questions regarding this .HOW document, or about dB2K you can communicate directly with the author and dBVIPS in the appropriate newsgroups on the internet.

.HOW files are created as a free service by members of dBVIPS and dBASE, Inc. employees to help users learn to use dB2K more effectively. They are edited by both dBVIPS members and dBASE, Inc. Technical Support (to ensure quality). This .HOW file MAY NOT BE POSTED ELSEWHERE without the explicit permission of the author, who retains all rights to the document.

Copyright 2001, Kenneth J. Mayer. All rights reserved.

Information about dBASE, Inc. can be found at:

EoHT: DEPLOY7.HTM -- January 30, 2001 -- KJM