Hi All,

I was browsing newsgroups, trying to find the answer to the following
question but failed.
Is there a memory leak problem with BDE to Oracle8i connection and how to
solve it. I ran several tests today and found that after several queries on
large table the error message appears ("Insufficient memory", used TQuery).
Is there any way to solve, or patch this?

Thanks.

        This is documented in the readme file (actually I think it's
bdereadme.txt).  It has to do with explicit Prepares.

        There is also a non-Oracle-specific BDE issue which can cause an
"insufficient memory" issue, but you didn't provide enough information
(such as the complete error text) for me to determine which one is the
problem.

        HTH,

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

Thank you Craig,
I've found this info in that file:
Workaround : call DbiQFree() and DbiQPrepare() every time the query is
executed.

Can anybody offer a piece of code like an example how to use them? I
couldn't even compile the unit with these functions.

Thanks.

"Craig Stuntz (TeamB)" <cstuntz@no_spam.vertexsoftware.com> wrote in message
news:3B704ED9.A40C5384@no_spam.vertexsoftware.com...

I'm not sure which is the problem exactly, but the code I'm trying to
redevelop is having explicit Prepares.....
Is that second possible problem documented somewhere?

"Craig Stuntz (TeamB)" <cstuntz@no_spam.vertexsoftware.com> wrote in message
news:3B704ED9.A40C5384@no_spam.vertexsoftware.com...

        The functions are documented in BDE32.HLP.  You need to add BDE to your
uses clause to call them.  Calling UnPrepare and Prepare would probably
suffice (or just don't use explicit Prepares and let the TQuery do it
for you implicitly) but may (I'm not sure) add some extra overhead that
the recommended workaround doesn't.

        As for the other issue, search your favorite newsgroup archive for
SHAREDMEMSIZE.  Since you still haven't said whether or not what you
posted was the full error message, I can't tell you if this problem is
relevant to what you're doing.  If you're doing explicit Prepares with
Oracle, it's probably the problem above, not this one.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

BTW, that's a completely and totally useless work around.  Closing the
query and reopening it totally eliminates the benefits of having a
prepared query since you are now making the server parse the SQL every
time you issue the query.

The bottom line is that you cannot use prepare on Oracle when using the
BDE if you are going to be issuing the query many times.  IMHO, this
should have been fixed in D6.  It makes using the BDE with Oracle highly
questionable because you may not be able to predict when you'll get the
error.

David R.

Quite right.

That's why everyone has switched to DOA or ODAC.  Perhaps DBExpress works;
I haven't tested it and have no reason to.

John Pierce

        I'm not sure.  There is some (fairly substantial) overhead with
TQuery.Prepare (fetching field lengths, etc. from the system tables)
which *might* not occur with DbiQFree and DbiQPrepare.  It's the only
reason I can think of that Borland would recommend it over not using
explicit Prepares.

        I haven't tested this theory, so if this concerns you, run it through a
profiler before you take my advice.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com