Lester,

> > 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.

Actually, it would be easier if maintained by the server -
For example, what do you do if the connection fails?
The server can cleanup the table after you, while you - with
your own mechanism - cannot, as you do not know that
your "attachment ID" is no longer a valid one.

Also, in all your procedures/queries/etc, there's no longer a
need to write:
"AND ATTACHMENTID = :MyID"


With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com