Introduction

BDE has been criticized because of perceived shortcomings regarding aliases, which are shortcuts to directories containing local database tables for your BDE client applications. Many developers find the maintenance associated with installing an alias into a local user's BDE32.CFG (or IDAPI.CFG) to be difficult at best.

The problem occurs when when you create a BDE application with Delphi, one using aliases to locate the application's tables. Simply put, aliases must exist for each user before your application will work.

We typically handle this by borrowing a concept from Paradox for Windows. While Paradox supports the traditional aliases (e.g. the ones publically saved to BDE32.CFG), it also supports project aliases, which are temporary aliases that go away when Paradox is exited. While you can save and reload project aliases in Paradox, they were originally designed to be temporary.

By adding a few lines of code to an appropriate OnCreate event handler, you can create your own project aliases in Delphi. (We usually do this during the OnCreate of a data module.) The following shows one way to do this:

var
   strAliasName,            // name for the temporary alias
   strAliasPath  : string;  // directory the alias points to

begin

   strAliasName := trimFileExt( extractFileName( paramStr( 0 ) ) );
   strAliasPath := getAppIni( 'Settings', 'DataPath', getWorkDir() + 'data\' );

   with Session do
   try
      screen.cursor := crHourglass;

      if not isAlias( strAliasName ) then
         addStandardAlias( strAliasName, strAliasPath, 'Paradox' );
   finally
      screen.cursor := crDefault
   end;  // with/try

In this implementation, we create a temporary alias named after the application itself. Also, we generally use standard .INI files to provide application configuration information. In this case, a DataPath setting can be supplied in the [Settings] section to point the application to data stored in another location. Please note that, by default, we assume our data files are available in a DATA\ directory below the one containing the .EXE file.

We've found this approach to flexible in supporting local, stand-alone users and file-server based applications.

For example, if the application is initially installed to a local hard drive, it eventually needs to be shared between multiple users. With this type of approach, you can easily "convert" the local application to a shared one simply by moving the files and changing the .INI file.

It's also a good idea to use similar code to control the network control directory (NETFILE) and the user's private directory. For example, we commonly do this by adding additional code to the snippet shown above:

   with Session do
   try
      screen.cursor := crHourglass;

      if not isAlias( strAliasName ) then
         addStandardAlias( strAliasName, strAliasPath, 'Paradox' );

      if getAppIni( 'Settings', 'NetDir', '' ) <> '' then
         netFileDir := getAppIni( 'Settings', 'NetDir', '' );
      privateDir := getTempDir;

   finally
      // ...

As the above shows, we often include a NETDIR setting in our application's configuration .INI that describes the location of the net file, as well as support user-specific sections for private directories, preferences, and other user-specific information.

We prefer .INI files for this sort of configuration because we've found that inexperienced users are more comfortable editing text files rather than the Registry. Also, if your primary line of support is the telephone, it tends to be easier to walk someone through the process of using Notepad as oposed to using the Registry Editor.

A INI-based configuration also simplifies the un-install process. The end-user simply deletes the application's directory and all subdirectories.

Again, these observations reflect our experience; your mileage may vary.

Please note that the above samples refer to custom routines we commonly use; these will be discussed in future articles.