Ann,

You have pretty much summed up how I wanted to do temporary tables
for Fyracle. As Fyracle largely sits between the client and the
engine, it can create the extra columns, views, etc. on the fly; it
can intercept attach/detach, commit/rollback and do some of the
cleanup automagically.

I guess this means too that it is conceivable to do a workable
implementation of temp tables by upgrading only the DSQL module. It
might be hard on the tool people, though.

Paul


--- In Firebird-Architect@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

> Given that we've largely agreed
>
> 1) that temporary tables must be created in a separate
> transaction and committed before use, and
>
> 2) that the definitions of temporary tables are visible
> to all attachments, and
>
> 3) that the <as subquery> clause is a separate issue
> with some significant complications, and
>
> 4) that a reasonable implementation of temporary tables
> is to add a (magic, invisible) field to the table
> that identifies records as belonging to a connection
>
> why do we need temporary tables at all? Why not use
> a conventional table with fields defined to contain
> the connection identifier and the current date? Those
> two fields can be filled in with triggers. Create a
> view that excludes the connection and date and filters
> on the connection, and you've got a temporary table,
> lacking only cleanup. Use a simple procedure that
> filters on the date field from time to time to remove
> data more than two weeks old.
>
> Not perfect, certainly, but free, and doesn't involve
> mucking with internals at all.
>
> Regards,
>
>
> Ann