In past versions of InterBase (version 4.x) there were some nasties I had to deal with when the cursor on the server
wasn't being closed properly. Memproof, assuming it just may be accurately taking the cursors on the server into account
properly, is merely taking notice that I am requesting the server to close a cursor more than once and then ignoring the
errcode that the server returns in the case that it has already closed it. By ignoring the errcode returned there is
absolutely no ill consequence in your application. I probably should make it only do that for the older version of InterBase
that needed that kind of quirk counteraction. Certainly it appears it is no longer necessary. This is part of the baggage
I've inherited by being around for more than 8 years. Seems it's time this got revisited. I know how discomforting it would
be for anyone to see so many things show up in MemProof.

As for the memory usage. Were you explicitly doing an Unprepare of your statements? This is most likely the cause for
your memory usage rising. It seems many middleware tools do an implicit unprepare for you unless you somehow explicitly
request it maintain your statement in a prepared state. WIth IBO I didn't do that because most all of my applications make
use of prepared statements and I either use execute immediate or explicitly unprepare statements I am only using on a
short-term basis. I'm sure if you looked in this area of your application your memory issues could be resolved.

In any case, if you are using a product that satisfies you more than IBO and you are chosing not to use IBO for anything
at all and your purchase was within 6 months from now, you are welcome to request a refund of your funds.

Contrary to your assumption that I don't give a *hit. I do care. I've just not been able to spend as much time in the support
forum lately as I would like. While IBO does quite well, I do maintain a full-time job and there are times that it demands
quite a bit of my time. We've been rolling out new software lately and that can be pretty demanding at times.

I do want to thank you very much for expressing detailed information and letting your frustrations out here where they can
be addressed. My apologies things didn't go as well for you as I hope for my customers.

Kind regards,
Jason Wharton

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
I posted this before and it seems no one gives a *hit.

Anyway I used a different component set (UIB) and all the errors
disappeard, and memory usage went way down.
To switch to the UIB components only required syntax changes i.e.
instead of IB_TRANSACTION it's just TRANSACTION.
If the server app now runs for more than 10 days I will be convinced
that IBO is not suitable for long running server apps.
I am kind of disappointed with this because I paid for IBO and UIB
is free (part of JVCL).


I don't know how accurate memproof is, but it is showing alot of
errors in IBO applications.
I renamed fbclient.dll to gds32.dll and then started my app from
memproof. I consistenly get the following errors:

# Item Kind Value Size Thread API Name
Module

3019 Dynamic SQL Error (17) SQL error code = -501 (21) Attempt to
reclose closed cursor
Error 000007D0 0 2748
isc_dsql_free_statement gds32.dll


the app runs fine, but I am concerned this could lead to long term
stability issues. Currently my app just blinks out after 10 to 14
days and I am leaning to the issue being with IBO.

There are no other errors in my app and no memory leaks. I have
tested it with memproof and memcheck, and the only errors to be
seen
are in IBO.
here is a screen shot
http://www.amsoftwaredesign.com/downloads/ibo_errors.PNG

I am using latest version of IBO and Firebird 1.5 final with
fbclient renamed to gds32.dll.

Tony