At 07:07 AM 30/12/2011, Daniel L. Miller wrote:

>Way back in my dark ages of programming (dBase III+) there was a concept
>of record recycling. This involved one or more methods of tracking
>deleted records - and then re-using those records. This was to avoid
>what dBase called the "pack" operation - which would be a subset of a
>Firebird sweep.

No, it's not a "subset of Firebird sweep". The "packing" concept is applicable to data storage systems that are based on files in which, theoretically or in practice, it is possible (and in some cases, necessary) to access "tables" and "records" at the physical level. Firebird is not such a system.

>Is there any reason for an application developer to implement such a
>strategy in their data access framework - or just let Firebird handle it?

There is neither reason, nor the means to do it. Provided the applications are written to take good care of transactions, Firebird collects its own garbage and frees up space occupied by obsolete record versions. Applications that are written to be "dumb" about transactions are likely to generate vast amounts of garbage - space on disk that can't be re-used because it contains obsolete record versions that can't be released, due to their being "still interesting" to one or more transactions, somewhere.

What you have to avoid is read-write transactions that never get committed. And, coming from file-based, non-transactional data systems, be fully aware that *everything* happens inside a transaction, including SELECTs.

./heLen