> I want to set up work tables, which gets filled and deleted thousands of
> times each day (I´ve complex structures created by app, what I don't
> want to save at definitive tables until them are confirmed). Can this
> method affect FB database general performance? (internal fragmentation,
> for example).

Fragmentation is not an issue for Firebird. As soon as you start using
the database, the data will start to spread across different pages
stored in different physical locations on the disk. The design expects
this to occur.

Bulk deletes will leave the data in the table until such time that it
is safe for the garbage collection to occur (after all potentially
interested transactions are complete). At that stage, the deleted
records are flagged as free and will be automatically reused when
Firebird needs to. Firebird 1.5 suffers when it is performing garbage
collection on indices with lots of duplicate values. Firebird 2 fixes
that specific issue.

> Do you have any suggestion about how to accomplish that,
> without using any memory or disk structures at client side?
>

Dropping and recreating the table is usually much cheaper, although
you can run into problems if you have a lot of dependencies or
multiple users using that table. You have access to the
CURRENT_TRANSACTION and CURRENT_CONNECTION context variables and
Firebird 2 introduces custom context variables that can be used to
distinguish records belonging to your transaction etc. Other options
are to use external tables (if it is insert only). I know temporary
tables are on the cards, but I do not think they are in 2.0.

Adam