Ann,

A> 1) that temporary tables must be created in a separate
A> transaction and committed before use, and

A> 2) that the definitions of temporary tables are visible
A> to all attachments, and

A> 3) that the <as subquery> clause is a separate issue
A> with some significant complications, and

A> 4) that a reasonable implementation of temporary tables
A> is to add a (magic, invisible) field to the table
A> that identifies records as belonging to a connection

A> why do we need temporary tables at all?

with the limitations above, not much. But I am a little lost as to how
the original requirements from Volker Rehn generated this whole
discussion about SQL standard temporary tables. They're not what
Volker needs, and not what people generally ask for when asking for
"temporary tables" in the support list. Nobody needs temporary tables
if they come with constraints 1, 2 and 4 above attached, so why
bother? Scoped table/cursor variables (with table/cursor as a
datatype) are what Firebird needs IMHO.

Ciao
--
Nando Dessena
http://www.flamerobin.org