At 05:11 PM 15/09/2004 -0400, you wrote:

>If you develop or are considering developing an interface
>tool that works with Firebird, I'd like your ideas about
>temporary tables. There's a discussion of creating temporary
>tables that are visible to a single attachment, persist
>across transactions, and are deleted with the attachment
>exits.

How big of a leap would it be to implement these temp tables as a special
class of external tables? I seem to recall, Ann, that you said there was
already unfinished stuff in place to support structured external table
files (dBase, CSV?)

It would take all but the metadata stuff right outside of
transactions. Indexing apart (which is likely to be a problem with temp
tables, whatever you do), the write-once-read-many model seems to be there
already and would offer more capabilities for the end use of the tables -
applications that want "tables" for displays and database reports have
them; and those that want external formats have them too.

Directory location decides who sees them - connection_id + transaction_id
determines who owns them.

Helen