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.

> The temporary table also has a special system created index on
> the attachment id. If it has a primary key or unique index, the
> attachment id becomes a segment of that key.

Not knowing how the intermediate results are currently created, I am
probably totally wrong, but isn't the internal table created before it
is sorted the thing that needs to be 'held over' for the next stage of a
complex calculation? Having just reduced a 7 query set of data down to 2
to produce a complex report, the results from FB1.5 in terms of time are
now good, while the same approach in FB1 was pig slow, hence building
the intermediate results manually originally.

Do we just need access to a 'cursor' on the intermediate results for
LOCAL temporary tables, and some additional internal functions for
managing data in GLOBAL temporary tables - which are just ordinary
tables with different rules on accessing the content?

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services