| Subject | Re: [IB-Architect] Database files > 2GB. |
|---|---|
| Author | Jim Starkey |
| Post date | 2000-04-26T22:09:01Z |
At 02:48 PM 4/26/00 -0700, Bill Karwin wrote:
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
consistency.
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.
off Interbase, it's a breeze.
Jim Starkey
>This is a relatively minor problem. At startup time, the engine
>
>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.
>
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
consistency.
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.
>Compared with the problems of prying Borland's greasy fingers
>This problem doesn't seem like it's unsolvable.
off Interbase, it's a breeze.
Jim Starkey