Subject | Re: Drop Table problem |
---|---|
Author | bmckenna6 |
Post date | 2005-06-16T02:00:11Z |
> You're cleaning a house before burning it down.Analogies can be very instructive, and the choice of metaphors
can loom large in memory. Remember "Burning Down The House!"?
That shared, I must plead my case, from my SQL beginners roots up:
my primary reference is Martin Gruber's "Mastering SQL."
I have no idea if his authority is worthy of my worship ;) or
what is really real here, but his book is where I go, rather than
always haunt the ngs.
(My apologies for any copyright issues Martin, but your
authority is at stake here.)
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.
That taken care of for now, what I've actually discovered is that my
DROP TABLE problem had some deeper dust kitties lurking.
All of my tables had been the subject of a query using
RDB$DATABASE, using that as a means of getting the fastest results
for basic tests in setting up the folder requirements for
a Virtual Treeview.
It turns out that another Transaction.Commit was missing, following
each of those queries.
I really don't want to spend TOO much time cleaning...just enough
so that it feels right :)
Barry McKenna