🚀 go-pugleaf

On Fri, 5 Nov 1999 08:55:19 -0800, "Bob Runyan" <bruny@lahey.com> wrote:

>I'm trying to deploy a simple database application that consists of an
>executable and a flat-file Paradox database.  I'm using Delphi 3.0 Pro.
>I've created an installation program with Install Shield Express.  My
>database is in a file called world.db.  I reference this in my program by
>the name "countries".
>
>Am I correct in thinking then that I need to set up "countries" as an alias
>in the BDE at installation time?
>
>When I attempt to deploy, I get:
>
>"Severe: Merging The Configuration File Has Failed.  Config File: C:\Program
>Files\Borland\Common Files\BDE\IDAPI32.CNF"
>
>then
>
>"Failed In Adding Alias:  The Error Number Is 3, Initialization Failed.
>
>I get nothing from these messages (other than puzzlement at the weird use of
>capitalization).  Can someone enlighten me?

You would need to look at the InstallShield references to see what they
mean by their error messages. But to me, those error suggest a corrupted
BDE configuration file.

>Also, is there a way to set up a single flat-file database so that I don't
>have to deal with all of this complexity?  Is there somewhere in the
>documentation where all of this is made clear?

Yeah, Delphi 3 was not very clear on that. I made quite a few changes for
the Delphi 4 help to clarify the situation.

First, though, I would make a clarification on terms. A Paradox file is a
"Table". A directory that contains Paradox and/or dBASE table files is a
"database". This is important in an explanation of how you reference one or
the other in an application.

In Delphi, you can specify a database in a number of different ways. One is
the DatabaseName property of dataset components (TTable and TQuery). This
property takes a String value containing: 1) the name of a BDE alias, 2) a
drive/directory reference (i.e., the database), or 3) a blank (see below
for #3). The DatabaseName property can be set at design-time using the
Object Inspector. It can also be set programmatically at runtime. The
latter looks like this:

  Dir := 'c:\Program Files\Borland\Borland Shared\Data';
  Table1.DatabaseName := Dir;
  Table1.TableName := 'Customer.db';

The TQuery offers one more way to specify the database: right in the SQL
statement. You can prefix a table name in a local SQL statement with a
drive and directory reference indicating the database containing the table.
Enclose that entire reference in quotation marks. If the database is
specified this way, leave the DatabaseName property of the TQuery blank.

  SELECT *
  FROM "c:\Program Files\Borland\Borland Shared\Data\Customer.db"

Another way to specify the database is with a TDatabase component. Assign a
PATH parameter in its Params property. Set the parameter to the drive and
directory containing the local tables. This approach is useful when you
want to specify the database in only one place, rather than at each dataset
component in the application. Set the DatabaseName property of the
TDatabase and each dataset component to the same string. This way, the
dataset components are associated with the TDatabase and will use its
connection to the database. All of this can be done at design-time using
the Object Inspector. It can also be set programmatically at runtime. The
latter looks like this:

  with Database1 do begin
    Connected := False;
    DriverName := 'STANDARD';
    Params.Clear;
    Params.Add('PATH=c:\Program Files\Borland\Borland Shared\Data\');
    DatabaseName := 'AppDB';
    LoginPrompt := False;
    Connected := True;
  end;

  with Table1 do begin
    Close;
    DatabaseName := TDatabase.DatabaseName;
    TableName := 'Customer.db'
    Open;
  end;

  with Table2 do begin
    Close;
    DatabaseName := TDatabase.DatabaseName;
    TableName := 'Orders.db'
    Open;
  end;

  ...

Note that when programmatically configuring the TDatabase like this, you
need to specify the driver type (set the DriverName property to "STANDARD")
and set the LoginPrompt property to False.

Because all of these approaches use a string to specify the database, you
have quite a bit of flexibility in how to store that information. It might
be a Windows Registry entry, an entry in an INI file, a passed string from
a custom set-up program, or a number of other conveyances.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Steve Koterski              "Health nuts are going to feel stupid someday,
Felton, CA                  lying in hospitals dying of nothing."
                                                              -- Redd Foxx