Thanks for your replies Svein and Paul, hopefully the following will help
clarify my problem.

There are two concurrent users at the time, both from the same process
(different threads though). Only one of the threads is doing any serious
writing, the other is monitoring the database for certain events every x
number of seconds (NOT using IB Events).

I am using the tiCommitted for the isolation level, and explicity commiting
after every 15 writes, or 15 seconds (the system averages 6 written records
/ second). Commit-Retaining is not used. In addition, I have verified that
the OAT is advancing normally. I cannot imagine how I could be any more
specific with my transactions.

Even if I exit the program and do a sweep, it fails to make a difference.

When I build the database, I spread it amongst different files, removing IB
5.6's limitation (my production systems are up to 180 gigs or so, the 200
gig barrier is still problematic).

I understand that hard drive space won't be reclaimed, but I need it to
reuse already allocated space for the records, instead of continuingly
growing the database size, until the last harddrive runs out of space (and
then corrupting the db).

-----Original Message-----
From: Paul Reeves [mailto:paul@...]
Sent: Wednesday, October 31, 2001 12:56 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Child Tables Problem Revisited


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



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/