Bill Morrison wrote:

>
>
> Now, the situation is still the same. I can sometimes read in the first
> record of child, but on certain systems after a certain number of records it
> fails to return.

A reproducible test case would be nice, although difficult to achieve, I
suspect. How many concurrent users are there when this happens?

> My application is constantly adding records to the end, and deleting records
> from the front (to keep the database from overflowing available disk space).
> Unfortunately, even though the parents are being deleted, the childs are not
> releasing the space they contain to be reused. Thus the database continues
> to grow until it wanders off the end of the drive and corrupts.
>

What transaction isolation are you using? When are you committing? Are you
using commit_retaining?

As Set has explained, IB won't release the space as long as it thinks that a
transaction has an interest in it. A single long running transaction (using
commit_retaining for instance) will block the engine from purging the deleted
records.

And if I recall correctly, you are usiing IB5.6, which does nothing to stop
the database expanding beyond the 2Gb/4Gb limit. Upgrading to the
soon-to-be-available Firebird RC1 will help overcome the corruption problem as
the file size limits are effectively removed. But the main issue, I believe,
is sorting out the transaction management. This will probably solve your other
problem, too.


Paul
--

Paul Reeves
http://www.ibphoenix.com
taking InterBase further