Hi Nickolay,

> > > Using the active database leverages the existing structures. Free
> > > space
> > can be located with existing mechanisms completely
> > > unchanged. Page number references in indexes and blobs can be used
> > directly. Cleaning up the pages used by a temporary table in
> > > the case of a system crash is problematic.
>
> I would simply add ATTACHMENT_ID system column (probably with
> appropriate index) to tables declared as temporary and taught optimizer
> to filter out rows which should not be visible by current attachment. At
> startup engine may perform simple clean up process (it doesn't require
> exclusive access to database and thus may be performed in background)
> which can delete rows belonging to old attachments.
>
> It looks like such implementation may be done in a few days and doesn't
> require big modifications of the engine.

Can we rely on the ATTACHMENT_ID after a server crash. Isn't there a chance
the same (or lower) one is choosen?

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Interbase and Firebird users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://80.126.130.81