Hi Helen,

> No, I ran out of energy for hunting needles in haystacks. I find it very
> tiring to troubleshoot problems ad infinitum when every response is based
> on conjecture, partial information and surprises. It takes hours of
> precious time and distraction and usually leads nowhere.

your comprehensive and informative answers are always very
appreciated. I have always wondered how you find so much time to write
so many long answers to so many people.
But if you think that my problem description is not sufficient, feel
free to tell me what (in your opinion) is missing. I will not get
upset by that (unlike some other people we know ;-)
As this problem is rather complicated, I found it very difficult to
decide which information should be provided and which not. Problem
reports for complicated problems have a tendency to get too large so
that nobody reads them ...

> To recap:
> You described the structures as "master-detail-detail" but you didn't
> provide any information about the relationships. Given that any
> master-detail relationship is implicitly 1:many, I could envisage problems
> where you were blindly using ib_cursors for every set. I had commented that
> possibly FastReport was trying to do some form of buffering resulting from
> your use of ib_cursors. You were going to try using ib_query instead of
> ib_cursor -- did you?;

I did today. And it seems that you had a good nose. Without any
tweaks, just with IB_Cursors changed to IB_Queries, the server memory
usage could be reduced significantly. With IB_Cursors, the server used
1250 MB of memory, with IB_Queries it was only 430 MB.
It seems that Fastreport does have some problems when it is used with
cursors. I will have a deeper look into the issue later.

What do you mean by "blindly using ib_cursors"? If this should mean
that it was wrong to use them, you are right. I just did not think
that FastReport would screw up when working with cursors, and as
cursors are the fastest way to retrieve rows using IBO, I thought it
was the right decision to use them.

> and you didn't answer my question about whether the
> application and the database server were running on the same machine.

You did not ask this as direct question, and enthusiastic about your
answer, it seems I did not recognize your indirect question ;-)

They do not run on the same machine, but it also does not make a
difference when they do.

> Therefore I think the matter rests with you at the moment...to provide a
> better description of the setup. From that exercise, it's even possible
> that you, as an experienced user of both IBO and Fb/IB, will happen upon
> the cause of the problem and recognise what's needed to fix it, or will be
> able to set up a test case for some possible bug in IBO or in FastReport's
> IBO support.

I will.
BTW, the main reason for my last posting was because nobody answered my
question about the page cache. You indicated that the page cache could
use a lot of server memory, and I replied:
"The default page cache size per database is 2048 pages, and my page
size is 8 KB. AFAIU the page cache should only consume 16 MB then?"
Can you confirm this?

> Sorry, I'm not Wonder Woman. :-)

Are you sure? ;-)

At least you gave a very good hint that lead me into the right direction.
I never would have had the idea to change the cursors to queries.
In these lists, it is always precious to read about other peoples'
proposals and points of view.

Even when they are formulated in a one- or two-liner ;-)


With kind regards,


Christian