Subject Re: [IB-Architect] Database files > 2GB.
Author Jim Starkey
At 02:48 PM 4/26/00 -0700, Bill Karwin wrote:
>The system table RDB$FILES stores the paths of secondary files and shadow
>files, but this is read-only; changing these values _doesn't_ change where
>InterBase looks for the secondary files.

This is a relatively minor problem. At startup time, the engine
can't reliably read RDB$FILES until all sections of the database
have been found (it is possible, even likely, that the database
record that records the file name of database file resides in that
file). As Bill mentioned, Interbase records (redundantly) the
names of all files in the database header.

Hacking together a utility isn't the answer. Interbase has a
very clean API and a very clean layering. The only right place
to add the code to manipulate database files is inside the engine.

Historically, Interbase has eschewed the use of DDL in favor of
active system table. Dynamic SQL, GDEF, et al, make direct updates
of the system tables to do data definition. It seemed like a good
idea at the time. It is probably best, although I would like to
hear from Charlie, that this style of interface be maintained for

The basic internal mechanism is that updates to system tables
are noted during record update and appropriate DFW (deferred
work blocks) are allocated against the transaction to indicate
that something meta-data-ish needs to be done as part of commit.

The "correct" (i.e. Interbase-like or Jim-like or whatever)
is to:

a. Define some appropriate DDL (sql, whatever) for the
appropriate utilities to mulch.

b. Understand and document the meanings of the appropriate
system table updates, extending the system tables if
absolutely necessary.

c. Recognize the system table updates in MET.E.

d. Execute the appropriate DFW blocks, also in MET.E.

The conventions for file names will always be problematic. It is
really up to the DBA (or whatever you call the guy that creates
database) to specify database filename that are appropriately
invariant. Neither the Unix guys nor the Gatesian have a real
good handle on the problem, so the other solution is to punt
and assume the humans are smart. This strategy is not guarenteed
to work in general.

>This problem doesn't seem like it's unsolvable.

Compared with the problems of prying Borland's greasy fingers
off Interbase, it's a breeze.

Jim Starkey