As there are many temporary tables and there may be a lot of users
during the day but no user during the night, what I wanted to do was
that the first that starts the application in a new day resets the
generator and so the generator wont increase forever. I know 2 ^ 31 is
a big number but anyway I wanted to to prevent...

It is a big number, 2,147,483,648 to be precise. I doubt you would
ever hit it.


If it really worries you define it as a bigint, then you get
9,223,372,036,854,775,808 which is most likely more than the number of
generator values your server could produce before the sun used up all
its hydrogen and imploded.

>
> I also thought using another identifier but the user may be

duplicated and the PC name too. I consider there may occur that an
instance of the application didn't finalize normally and some
temporary tables remain in the temporary database and so there may be
conflict between the tables of an instance and the tables created by
the same PC the day before if there is some that wasn't deleted.

>
> May be my idea is a bit foolish, but anyway... is there a way to do

this?

Yep,

select CURRENT_CONNECTION
from RDB$DATABASE;

If current_connection was 5, then you would want to make sure the
table tmp_5 was emptied before doing anything.

Keep in mind that the old records in the tmp table are still there
until the delete commits and any other transaction that may be
interested in the old tmp table values commits and the garbage
collection then happens. Even then, FB will continue to hold the disk
space the OS allocated it (but it will re-use it if required).

Even so, do not make long term plans for keeping this database
structure. It is a fine stop-gap measure to get the thing to run, but
it will get in your way in the future.

Adam