On Wed, 24 Nov 2004 08:59:08 +0000, Lester Caine wrote:

>
>Ann W. Harrison wrote:
>
>> Ah. Nickolay just called and explained what I had missed. The idea
>> is that a temporary table has one more column than its definition
>> includes. That column contains the attachment id of the transaction
>> that stored the record. Attachment ids are handed out like transaction
>> ids, through the header page, but without the record-keeping that
>> transactions require.
>
>Which sounds exactly how I use my current 'temporary tables'. Define a
>normal table, with a used_id column, and then clear down in a trigger
>when the results are written. While I can see the advantage of a
>'temporary table', I can't see the 'need' for it, when one can easily
>create something appropriate for your own requirements using the
>existing facilities.

When Firebird implements SQL between multiple databases and
there´s a need for data migration between two (for example,
very complex simulation database and a enciclopedic database where the
first
migrate data from the second and the two doesn't have exactly
the same structure), temp tables is a AMAZING tool to easy the
formating before inserting. I use them a lot on my MSSQL job and
saved my neck in a lot of times.