At 05:55 PM 21/06/2003 +0700, you wrote:

>My sistem does not need such record delta mechanism, though I may still
>need it in other time in other system. It'd be better if that feature is
>customizable, put it somewhere in the configuration file. So, I can
>decide whether I want to use it or not.
>
>Firebird is a great database system with rich features. Though I'm a
>newbie with it, I already love it. But, this problem which I think it
>should be easy to solve, seems too complicated to be done. Maybe, this
>can be a wish list from me to the Firebird developers, though I can't
>help with the code perhaps I still able to help with suggestions.

Unfortunately, you are looking for a file-based database to do what you
want, and a transaction-driven, multi-generational database is not designed
to do it.

That said, the times and sizes you report at least show that something is
terribly wrong with what you are doing. If you can get past the need you
perceive to not hold back-versions (which Firebird does to protect your
data in a multi-user environment) we can give some guidance on how to
prevent your database from growing so much and from degrading in
performance. 6 mins for 50,000 updates is ludicrous and for it to keep
getting worse means your client environment is killing the garbage collection.

>For now, run gbak periodically is the only solution to overcome this
>problem.

gbak is very useful for getting rid of garbage, but you need to repair your
application code so that you are not accumulating so much garbage. gbak
doesn't overcome the problem, it only cleans up the mess which the problem
creates. You'll need to provide a better problem description if anyone is
to be able to assist you.

heLen