If after a sweep the very next update grows the database, there are only a
few options:
1) That someone is keeping a transaction open for a long time (watch
IBConsole, Server Mgr, WISQL, other housekeeping bots).
2) That there is an early transaction in limbo.
3) You are actually putting more data into your tables than you think <g>

Go the whole hog, and run gstat for both header, data and index pages at the
following points:
1) at the beginning of the day prior to updates
2) after the updates, but prior to the sweep
3) after the sweep.

Do this for a couple of cycles and then look at the different outputs. I
use a diffing tool (VSS at work), to compare such files. You should be
looking for the transactions to move on and the page usage to stabalise.

Hoy many days have you let it run for, did it just keep growing linearly?

JAC.

> Thanks for your help Paul, will try gstat und gfix.
> Yes, I don't want to shrink the database-file-size, just reuse the
> space allocated f=FCr version records. but in my case it seems that
> sweep does not help because directly after a sweep the next updates
> again increase the db-file-size, but these updates should first use
> the space freed by the sweep!??

> It seems that I have an old open transaction, how can I close/kill
> such a transaction?

gfix has a switch to rollback or commit a transaction, but it is designed
for limbo transactions, no idea what it would do with a normal transaction
that isn't in limbo.

We periodically take the ib service down or reboot the server (you can cause
the same by shutting the database down).

JAC.