bmckenna6 wrote:

>
> my primary reference is Martin Gruber's "Mastering SQL."

In this particular case, Firebird doesn't follow his model of how a
database works.

> (My apologies for any copyright issues Martin, but your
> authority is at stake here.)

At least in the US, this is what is called "fair use" and not a
copyright violation.

>
> p.41 "Dropping a Table"
>
> Dropping a table is actually a two-step process, as follows:
>
> - First you must empty the table of any data by using the
> DELETE statement.
> - Then you can destroy the definition of the table by using the
> DROP TABLE statement.
>
> Perhaps things have evolved a bit. I haven't a clue why you differ
> in your housecleaning philosophy.

There may be databases that disallow dropping tables with data in them.
Firebird isn't one of them. Firebird won't let you drop a table if it
has dependencies - views, procedures, triggers, etc. - that reference
it. You have to remove or change the dependent objects first, then drop
the table.

Here's what happens in Firebird when you delete a record.

1) lookup the record
2) check for unneeded back versions
a) if there are any, remove them
b) remove index entries that applied to those versions
3) create a deleted stub for the record
4) determine whether the page with the record has room for a
deleted stub and the back version.
a) if not, find a page that has room for the back version
b) write the back version there
5) write the stub with a pointer to the back version

Then start again with the next record. The process will write every
data page in the table - possibly more than once.

Dropping a table removes its description from the system table, then
marks the data pages as free without writing them - only the page
inventory pages (PIPs) are written, only once per PIP - and they're
very dense - one bit per page inventoried.


Regards,


Ann